@@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.
9:05 oh crap i normally just return tasks from lambdas expecting a task return. whats the difference between that and making it an async lambda like u have here?
How does this resilience handler works across different servers/instances? If application hits some transient error by calling an endpoint from server 1, will server 2 call the endpoint and hit the transient error again or will it know that server 1 had already made call and an error occurred? Thanks
@@aweklinsame. 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 🙂.
I can understand the first half of the video. What is the second half doing? I mean adding provider, and then removing http client and add the standard handler?
Very cool, but I have to ask, what if you are injecting that policy into multiple services that each make aj http request, and you send up those requests simultaneously using Task.WhenAll? Is the pipeline registered to be injected in a Transient scope, or are you getting a singleton pipeline, thus limiting you to one operation at a time?
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.
Great stuff! I am thinking about a very common situation: paralleism. Your method is called concurrently. let's say you have a named pipeline for a specific task. The policy is reusable, all right, but in an idempotent way, or does it have a state? If - for example - the circuit is broken in one call, it should (if needed for specific task cases) immediately fail for all the other subsequent calls until reset. In other scenarios the policy calls can be independent. Is there support for such a thing?
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
I didn't know about this, and it looks very cool. Can it be used for Mongo/Cosmos retries, where the exception tells you how long you should wait before retrying?
Hi! Is it really good idea to have resilience pipeline as a static instance, in such case it must be thread safe, because single pipeline instance has to serve many requests there?
If I have many services I prefer to have the service setup within that service implementation and not part of it in the centralized DI setup. I guess that means I cant really use the HttpClient/HttpClientFactory approach with included resilience since I would have to set this up in the central DI setup, right?
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).
To answer your question at the end of the video: not knowing of the name of this concept, we wrote our own stuff to do this. I'm going to forward this to the team so we can do better moving forward.
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.
I sadly still work in framework 4.7.2 and usually use Polly if I need a simple retry. Because I work with a lot of multi tenant to single tenant application lately I've been using queues to provide a rudimental retry mechanism and data persistency
Is it possible to chain pipelines? For example have a default pipeline but also I wish to have some specific handling in a specific request, and have that on top of the basic pipeline. Some cases I may want to override parts of the strategies of the default pipeline, and some cases I just want to add to it.
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)
Does this also have support for persistence and long-running retries? Like, if the request fails, retry it in a few hours, but in the meantime our application could potentially be restarted 😅
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.
This sounds like a perfect way to handle jwt access token expiry. You can configure to retry with the refresh token one time on failure of access token due to expiry.
In the weatherserivce class should you name it "_resiliantHttpClient" to distinguish it from a standard httpclient? How can we make sure the reader of the service knows it's resilient without them looking at the DI config?
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.
Is there a way how to test those policies? Polly has Simmy, so I was wondering if the same alternative exists or planned to be shipped in the future. P.S. I looooove that .NET finally offers such a nice API for such a basic problems!
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.
It's not bad, but it seems a bit more verbose compared to just using Polly. And they went with stringly typed DI again 🤨 but at least it seems you can use other types as key.
I can understand that there's an argument for supporting retry and circuit breakers for old school hosting of services or if you just have a need to do it all yourself. In my opinion there are better places for handling these problems than in the code.
Polly lost me with V8 and their removal of the cache policy. Their whole API got strange and they omitted the cache and distributed cache policy which was golden when used with the request deduplication policy. Even the absence of bulkhead is a downgrade
@@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🍀
I love this. Finally learnt about resilience in an extremely easy way!
Thanks Nick.
learnt, wtf. Have you tried learnting english just saying wow. Programmers who are illiterate is apparently a thing.
Damnit, it was enough of an adventure getting my team to use Polly
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
I wrote my own resilience class 7 years ago which does most of this. But time to modernise! Awesome content.
why is using a jitter more important for exponential backoff than linear? or did i misunderstand that
It's not. I mixed it up, it's actually less important but still important
9:05 oh crap i normally just return tasks from lambdas expecting a task return. whats the difference between that and making it an async lambda like u have here?
The only real difference would be whether you can await inside the lambda. It's producing a Task either way.
sometime ago, I wrote a wrapper class for polly to combine policies in a dynamic way :)
How does this resilience handler works across different servers/instances? If application hits some transient error by calling an endpoint from server 1, will server 2 call the endpoint and hit the transient error again or will it know that server 1 had already made call and an error occurred? Thanks
How this works with Refit C#
You can add httpclient in refit interface by ConfigureHttpClient
Great video and explanation. Thanks Nick!!
Why did you delete the primitive obsession video?
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.
@@aweklinsame. 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 🙂.
@@aweklinSame! I went back to comment, and it said the video is now private.
I can understand the first half of the video. What is the second half doing? I mean adding provider, and then removing http client and add the standard handler?
Your video is just in time, Nick. I needed to implement this logic in api today)
Nick of time :)
Very cool, but I have to ask, what if you are injecting that policy into multiple services that each make aj http request, and you send up those requests simultaneously using Task.WhenAll? Is the pipeline registered to be injected in a Transient scope, or are you getting a singleton pipeline, thus limiting you to one operation at a time?
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.
Is it a good idea to place that nice resilience pipeline inside a try/catch block?
Great stuff! I am thinking about a very common situation: paralleism. Your method is called concurrently. let's say you have a named pipeline for a specific task. The policy is reusable, all right, but in an idempotent way, or does it have a state? If - for example - the circuit is broken in one call, it should (if needed for specific task cases) immediately fail for all the other subsequent calls until reset. In other scenarios the policy calls can be independent. Is there support for such a thing?
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
I didn't know about this, and it looks very cool. Can it be used for Mongo/Cosmos retries, where the exception tells you how long you should wait before retrying?
awesome sample! thanks for sharing!
Hi! Is it really good idea to have resilience pipeline as a static instance, in such case it must be thread safe, because single pipeline instance has to serve many requests there?
Can we add logic to detect retryable vs non-retryable errors?
Absolutely. On the ShouldHandle method
If I have many services I prefer to have the service setup within that service implementation and not part of it in the centralized DI setup. I guess that means I cant really use the HttpClient/HttpClientFactory approach with included resilience since I would have to set this up in the central DI setup, right?
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).
To answer your question at the end of the video: not knowing of the name of this concept, we wrote our own stuff to do this. I'm going to forward this to the team so we can do better moving forward.
2:36 the city query string parameter value is not url encoded. 🙂
Great Content! Is there also a Microsoft builtin for token management?
Nice video. However, what is now better than using Polly?
Hey Nick! Love your videos. Is there any reason in particular for you using Rider instead of Visual Studio? Would love to know.
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.
I sadly still work in framework 4.7.2 and usually use Polly if I need a simple retry. Because I work with a lot of multi tenant to single tenant application lately I've been using queues to provide a rudimental retry mechanism and data persistency
Nick thank you for this video. Can you give us what your favorite VS Code extensions are for C#?
Is there a way to use this library in Blazor?
Will this replace the result pattern as this can handle any exception so having both could be overkill, right?
You can handle both results and/or exceptions.
What happened to your previous video?
Is it possible to chain pipelines? For example have a default pipeline but also I wish to have some specific handling in a specific request, and have that on top of the basic pipeline.
Some cases I may want to override parts of the strategies of the default pipeline, and some cases I just want to add to it.
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)
Did you find a solution for this?
6:53 "by the power of one, by the power of two, by the power of maaaany" (sorry Nick, I had to :))
From the bottom of all SW fans: fu 🖕😂
@@KingOfBlades27 what did I do to deserve such a treatment from, as you claim "all SW fans?"
@@Velociapcior That should be quite self-evident 😂
@@KingOfBlades27 it's not evident to me, please enlighten me, what did I do wrong?
@@Velociapcior Quoting a ridiculous scene from a show that overwhelming amount of viewers hate 😂
Does this also have support for persistence and long-running retries? Like, if the request fails, retry it in a few hours, but in the meantime our application could potentially be restarted 😅
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.
This actually looks really cool
This sounds like a perfect way to handle jwt access token expiry. You can configure to retry with the refresh token one time on failure of access token due to expiry.
Does Refit integrate with this Microsoft resilience package?
Yeap
In the weatherserivce class should you name it "_resiliantHttpClient" to distinguish it from a standard httpclient? How can we make sure the reader of the service knows it's resilient without them looking at the DI config?
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.
Is there a way how to test those policies? Polly has Simmy, so I was wondering if the same alternative exists or planned to be shipped in the future.
P.S. I looooove that .NET finally offers such a nice API for such a basic problems!
I think they hardcoded 'Clouds' for London.
That's very slick I must say
You removed the previous video about using primitives
No way
@@nickchapsas yes way! :) correction: made it private.
This is nice but lets go back to: On Error Resume Next! No need for error handling.
So Polly is not needed anymore?
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.
Why you removed your latest video?
To remake it with more context
Primitive obsession feels like April Fools' day video. But It's June now)
So why is this better than Polly?
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.
Why is it -1 dependency? This is also a Nuget package.
This is so good 🎉
There were Polly references in the code though...
Noticed this as well...
Why are you still not using primary constructors for DI?
because they are bad for DI readonly fields.. ?
Because readonly is not supported yet
Why is it not using keyed injection instead of injecting the provider? What a missed opportunity!
Adding logging when each retry occurs would be nice. Log.Warning for each retry, then Log.Error when all retries have been exhausted.
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
It's not bad, but it seems a bit more verbose compared to just using Polly.
And they went with stringly typed DI again 🤨 but at least it seems you can use other types as key.
Polly works with anything not just HTTP specific contexts.
Beautiful.
I can understand that there's an argument for supporting retry and circuit breakers for old school hosting of services or if you just have a need to do it all yourself.
In my opinion there are better places for handling these problems than in the code.
hi nick
Polly lost me with V8 and their removal of the cache policy. Their whole API got strange and they omitted the cache and distributed cache policy which was golden when used with the request deduplication policy. Even the absence of bulkhead is a downgrade
Finally!!!
5:41
Hello Weather examples are fine, how about a real world example using Refit with rate limit handling and logging; that was my task today
I usually handroll my own stuff. Where I work the 3rd party packages are frowned upon.
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?
Microsoft.Extensions.Http.Resilience uses Polly under the hood. Is this why you use word 'directly' in the title?
Yeap
Wowww
Waters muddied 😭
Hey nick I’d love a job 🙏
Offtopic:
Why you chose Insomnia over Postman? 😀
Postman is pay2win 😂
Builtin http client in Rider is a lot better than those two.
OR! You can use service mesh.
Or rewrite to Rust. Lol.
⚰️ polly
Man that voice is weird, really weird. I miss fingernails scraping the chalk board after hearing 2 seconds of it argh lol