Don't Use Polly in .NET Directly. Use this instead! 

You're on the right path

@@nickchapsas If a team plans to implement this in a microservice project with Kubernetes, I recommend using a service mesh mostly with CNCF products like lined/istio. It has all the necessary features, including the telemetry and observability MTLS, and all features can be implemented along with fine-tuning the behavior, like the number of retries, etc., just by YAML definition without touching the actual source code.

But it's still using Polly in the background, or am I wrong? AddStandardResilienceHandler is using ResiliencePipelineBuilder in the background and ResiliencePipelineBuilder is from Polly. Microsoft just defined some "standard" resilience pipeline, that is all.

@@marekmagath7090 Yeah for that standard case sure. But we're doing some much lower level stuff, not just typical network HTTP requests

Nick of time :)

For the circuitbreaker to work it needs to store state e.g. how many failures, is the circuit open or closed. If you use the same pipeline for all requests then the circuit will break for one and then all of the others too. If you want independent behaviour then you need separate pipelines

For parallel calls then the concurrency option might be of interest

A lot of us Rider users probably started as Resharper users as .NET Core came about When I started using Rider(about 5 or 6 years) I found it to be significantly faster than Visual Studio, allowed me to use Linux, and I was coming from IntelliJ and PHP Storm

It is much better IDE for non-desktop projects. Combines ReSharper with a simple strealined UI. And if you are user of JetBrains tools, you are at home in all of them.

@@mx0r could you be more specific on it being "better for non desktop apps?" are you saying it as in better for web apps, sockets/threads related stuff, etc.?

i use it because I'm on mac and I don't like the visual studio for mac. don't like the performance hit of using it in a windows vm but that's what I used to do.

@@Natusch_If you want to do XAML-based stuff, there is no visual editor or preview in Rider. So I usually did the desktop applications in VS+ReSharper and the usual backend things in Rider.

It's not. I mixed it up, it's actually less important but still important

I don't know if it's possible to chain pipelines, but at least it's very easy to make your own pipeline builder extensions to simplify the pipeline creation (so you will have some kind of duplicates of pipeline objects, but in memory, not in code)

I wanna remake it with more context

More dometrain context? 😅

Thought I was the only one who noticed it. But I had finished watching & wanna comment before realizing it was deleted! It was great @Nick.

​@@akeemaweda1716same. I got "This action is forbidden" when I tried to post a comment. Weirded me out. At least I saved the comment on OneNote for next time 🙂.

​@@akeemaweda1716Same! I went back to comment, and it said the video is now private.

Absolutely. On the ShouldHandle method

You can handle both results and/or exceptions.

You can add httpclient in refit interface by ConfigureHttpClient

I think the pipeline is configured and implemented to handle multiple concurrent operations safely, and as mentioned in the doc, the pipeline is registered as a singleton but it is implemented to maintain separate state for each execution. For the Task.WhenAll, each request will go through the same pipeline instance, but it will have its own execution context and state.

You can make an extension method for IServiceCollection in the same file as your service that wires that service and anything else it needs. So you have the code there and only call it in the startup method (I guess you could even avoid having to do that with automatic wiring using reflection). I generally prefer to use DI for everything if I'm already using DI. Why avoid the benefits of easy mocking, being able to see all the services in one big list... if you're already using it.

@@gileee I currently use the approach to just inject the httpclientfactroy (yes setup globally using DI) and then in the service I would create a client and use a service specific resilience (the resilience not from DI), that way Program.cs/Startup.cs doesn't contain any "service specific" logic which I find nice. I am still curious if I can somehow improve on the pattern... I guess I could globally setup some basic resilience pipeline (not service specific) and then use that one in the service. I guess the key point is the HttpClient/HttpClientFactory which I don't like to setup service specific in the main Program even if the setup is from an extension method from the service code (it still would introduce a service specific setup in the main program (beyond the DI setup of IService -> Service implementation which is of course needed somewhere).

Recommendation is not to have really long timeouts/retry intervals. For that you could look at a task scheduler like Quartz or Hangfire. If a job fails then schedule it for later. You could use the fallback for that.

Yeap

The truth is you always need to know what's in the config. What database is used, where logs are stored and so on. So appsettings.json and Program.cs (+optional Startup.cs) are places you need to learn by heart

​@@isnotnullExactly, naming it a 'resilientHttpClient' still does not provide you any clues as to which policies are applied without digging through the DI bootstrap.

because they are bad for DI readonly fields.. ?

Because readonly is not supported yet

No way

​@@nickchapsas yes way! :) correction: made it private.

This I need. I need to log retries/failures to pass on that telemetry to my other team who support the service. I had to roll out my own even after looking at Polly.

@@pazzuto You can do it with Polly. We do.

@@robrider838 I see they added telemetry in v8. Nice! I'll be taking a look. Thanks so much for pointing it out.

Yep it does log when it retries

Polly of version 8, has the same api and provides the same experience when build a pipeline. So, you can use any of packages at least for now.

@@eugene3685In fact, Microsoft.Extensions.Resilience uses Polly.Core 8.x under the covers. You can just reference Polly.Core and that's it.

Noticed this as well...

To remake it with more context

Primitive obsession feels like April Fools' day video. But It's June now)

Not sure if he somewhere states that it is better, but -1 dependency

@@Mio2k10 The title currently says "Don't Use Polly in .NET Directly. Use this instead!". I was wondering about the same thing.

Or rewrite to Rust. Lol.

Lame! Refit and Polly make me so much more productive.

@@philosophersam If you do contract work on critical software and your paycheck gets delayed from rejected security review you will understand why we have to 'handroll' our stuff, you also have to lick your screen before every commit for better luck🍀

@@fatlumlatifi2897sounds like overzealous security policies. Why waste time and reinvent the wheel if there are good packages out there?

Yeap

Postman is pay2win 😂

Builtin http client in Rider is a lot better than those two.