Damnit, it was enough of an adventure getting my team to use Polly
@nickchapsas5 ай бұрын
You're on the right path
@jojify5 ай бұрын
@@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.
@marekmagath70905 ай бұрын
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.
@AvenDonn5 ай бұрын
@@marekmagath7090 Yeah for that standard case sure. But we're doing some much lower level stuff, not just typical network HTTP requests
@aweklin5 ай бұрын
I love this. Finally learnt about resilience in an extremely easy way! Thanks Nick.
@jamesgoforth5644Ай бұрын
learnt, wtf. Have you tried learnting english just saying wow. Programmers who are illiterate is apparently a thing.
@iBeechus3 ай бұрын
I wrote my own resilience class 7 years ago which does most of this. But time to modernise! Awesome content.
@futurexjam25 ай бұрын
sometime ago, I wrote a wrapper class for polly to combine policies in a dynamic way :)
@ChrisWard745 ай бұрын
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?
@mariacobretti5 ай бұрын
why is using a jitter more important for exponential backoff than linear? or did i misunderstand that
@nickchapsas5 ай бұрын
It's not. I mixed it up, it's actually less important but still important
@atziazas4 ай бұрын
Nick thank you for this video. Can you give us what your favorite VS Code extensions are for C#?
@Natusch_5 ай бұрын
Hey Nick! Love your videos. Is there any reason in particular for you using Rider instead of Visual Studio? Would love to know.
@kabal9115 ай бұрын
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
@mx0r5 ай бұрын
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.
@Natusch_5 ай бұрын
@@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.?
@DiddleDangle5 ай бұрын
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.
@mx0r5 ай бұрын
@@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.
@zoltanzorgo5 ай бұрын
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?
@Workshopshed5 ай бұрын
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
@Workshopshed5 ай бұрын
For parallel calls then the concurrency option might be of interest
@sebastianfriedrich7545 ай бұрын
Great Content! Is there also a Microsoft builtin for token management?
@bensmith60044 ай бұрын
This actually looks really cool
@UrsEnzler4 ай бұрын
Nice video. However, what is now better than using Polly?
@rodrigo64595 ай бұрын
Is it a good idea to place that nice resilience pipeline inside a try/catch block?
@ThisIsStupid123123125 ай бұрын
This is nice but lets go back to: On Error Resume Next! No need for error handling.
@xaberue5 ай бұрын
awesome sample! thanks for sharing!
@1hotsteppa83Ай бұрын
Great video and explanation. Thanks Nick!!
@amirhosseinahmadi37065 ай бұрын
Why did you delete the primitive obsession video?
@nickchapsas5 ай бұрын
I wanna remake it with more context
@Wouldntyouliketoknow25 ай бұрын
More dometrain context? 😅
@aweklin5 ай бұрын
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.
@phizc5 ай бұрын
@@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 🙂.
@Tsunami145 ай бұрын
@@aweklinSame! I went back to comment, and it said the video is now private.
@eugene36855 ай бұрын
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?
@kabal9115 ай бұрын
That's very slick I must say
@fezhaez5 ай бұрын
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
@Velociapcior5 ай бұрын
6:53 "by the power of one, by the power of two, by the power of maaaany" (sorry Nick, I had to :))
@KingOfBlades274 ай бұрын
From the bottom of all SW fans: fu 🖕😂
@Velociapcior4 ай бұрын
@@KingOfBlades27 what did I do to deserve such a treatment from, as you claim "all SW fans?"
@KingOfBlades274 ай бұрын
@@Velociapcior That should be quite self-evident 😂
@Velociapcior4 ай бұрын
@@KingOfBlades27 it's not evident to me, please enlighten me, what did I do wrong?
@KingOfBlades274 ай бұрын
@@Velociapcior Quoting a ridiculous scene from a show that overwhelming amount of viewers hate 😂
@kirillhorn31865 ай бұрын
Your video is just in time, Nick. I needed to implement this logic in api today)
@NawfalHasan5 ай бұрын
Nick of time :)
@jwtly2005 ай бұрын
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?
@surajbangale8395 ай бұрын
How this works with Refit C#
@ИванУмнов-я7с5 ай бұрын
You can add httpclient in refit interface by ConfigureHttpClient
@wusswuzz58185 ай бұрын
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.
@magicsmoke05 ай бұрын
Can we add logic to detect retryable vs non-retryable errors?
@nickchapsas5 ай бұрын
Absolutely. On the ShouldHandle method
@jonathanblackwell425 ай бұрын
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.
@stephajn5 ай бұрын
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?
@zakaria_ml5 ай бұрын
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.
@dennisvandermeer82385 ай бұрын
Will this replace the result pattern as this can handle any exception so having both could be overkill, right?
@Workshopshed5 ай бұрын
You can handle both results and/or exceptions.
@texasyobro5 ай бұрын
Is there a way to use this library in Blazor?
@rngesus80575 ай бұрын
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?
@JoshWeeksАй бұрын
The only real difference would be whether you can await inside the lambda. It's producing a Task either way.
@たろ羊5 ай бұрын
What happened to your previous video?
@alonmore285 ай бұрын
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.
@volan4ik.5 ай бұрын
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)
@JonasJermann5 ай бұрын
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?
@gileee5 ай бұрын
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.
@jjermann25 ай бұрын
@@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).
@henningerhenningstone6915 ай бұрын
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 😅
@Workshopshed5 ай бұрын
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.
@antonmartyniuk5 ай бұрын
Does Refit integrate with this Microsoft resilience package?
@nickchapsas5 ай бұрын
Yeap
@Grymyrk5 ай бұрын
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?
@isnotnull5 ай бұрын
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
@DustyBg5 ай бұрын
@@isnotnullExactly, naming it a 'resilientHttpClient' still does not provide you any clues as to which policies are applied without digging through the DI bootstrap.
@Chorniyko5 ай бұрын
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!
@robrider8385 ай бұрын
Adding logging when each retry occurs would be nice. Log.Warning for each retry, then Log.Error when all retries have been exhausted.
@pazzuto5 ай бұрын
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.
@robrider8385 ай бұрын
@@pazzuto You can do it with Polly. We do.
@pazzuto5 ай бұрын
@@robrider838 I see they added telemetry in v8. Nice! I'll be taking a look. Thanks so much for pointing it out.
@PaulNicholsAUS5 ай бұрын
Yep it does log when it retries
@extremedrone53655 ай бұрын
You removed the previous video about using primitives
@nickchapsas5 ай бұрын
No way
@paulkoopmans46205 ай бұрын
@@nickchapsas yes way! :) correction: made it private.
@csabraxas4 ай бұрын
Polly works with anything not just HTTP specific contexts.
@jakebradminster709Ай бұрын
I think they hardcoded 'Clouds' for London.
@rodrigodearcayne5 ай бұрын
So why is this better than Polly?
@Mio2k105 ай бұрын
Not sure if he somewhere states that it is better, but -1 dependency
@eirik84405 ай бұрын
@@Mio2k10 The title currently says "Don't Use Polly in .NET Directly. Use this instead!". I was wondering about the same thing.
@zeko77tz5 ай бұрын
Beautiful.
@rngesus80575 ай бұрын
hi nick
@chris-pee5 ай бұрын
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.
@nocgod5 ай бұрын
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
@paulovictor94395 ай бұрын
Why you removed your latest video?
@nickchapsas5 ай бұрын
To remake it with more context
@IamSystemko5 ай бұрын
Primitive obsession feels like April Fools' day video. But It's June now)
@jchandra745 ай бұрын
So Polly is not needed anymore?
@eugene36855 ай бұрын
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.
@IAmFeO2x5 ай бұрын
@@eugene3685In fact, Microsoft.Extensions.Resilience uses Polly.Core 8.x under the covers. You can just reference Polly.Core and that's it.
@amirhosseinahmadi37065 ай бұрын
Why are you still not using primary constructors for DI?
@luk4sz985 ай бұрын
because they are bad for DI readonly fields.. ?
@nickchapsas5 ай бұрын
Because readonly is not supported yet
@PhilHeighes5 ай бұрын
Hello Weather examples are fine, how about a real world example using Refit with rate limit handling and logging; that was my task today
@androidsavior5 ай бұрын
Wowww
@lalithprasadsrigiriraju5 ай бұрын
This is so good 🎉
@GigAHerZ645 ай бұрын
Why is it not using keyed injection instead of injecting the provider? What a missed opportunity!
@IssaFram5 ай бұрын
There were Polly references in the code though...
@kell76895 ай бұрын
Noticed this as well...
@Lovecraft815 ай бұрын
Finally!!!
@Milk-gw1zl4 ай бұрын
5:41
@vkovalyuk5 ай бұрын
Microsoft.Extensions.Http.Resilience uses Polly under the hood. Is this why you use word 'directly' in the title?
@nickchapsas5 ай бұрын
Yeap
@krigrtrue5 ай бұрын
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.
@T___Brown5 ай бұрын
Waters muddied 😭
@jessecavada30155 ай бұрын
2:36 the city query string parameter value is not url encoded. 🙂
5 ай бұрын
I usually handroll my own stuff. Where I work the 3rd party packages are frowned upon.
@philosophersam5 ай бұрын
Lame! Refit and Polly make me so much more productive.
@fatlumlatifi28975 ай бұрын
@@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🍀
@M0J0-RL2365 ай бұрын
@@fatlumlatifi2897sounds like overzealous security policies. Why waste time and reinvent the wheel if there are good packages out there?
@KRTone1235 ай бұрын
OR! You can use service mesh.
@PeriMCS5 ай бұрын
Or rewrite to Rust. Lol.
@orthodox-4-ever5 ай бұрын
Offtopic: Why you chose Insomnia over Postman? 😀
@mariocamspam725 ай бұрын
Postman is pay2win 😂
@PeriMCS5 ай бұрын
Builtin http client in Rider is a lot better than those two.
@Ocean76535 ай бұрын
Hey nick I’d love a job 🙏
@mbalaganskiy5 ай бұрын
⚰️ polly
@jamesgoforth5644Ай бұрын
Man that voice is weird, really weird. I miss fingernails scraping the chalk board after hearing 2 seconds of it argh lol