Using Polly, the resilience framework for .NET, you can gracefully handle the lost packets, thrown exceptions, and failed requests which inevitably make their way into service-to-service communications on the web. A previous post on the Twilio blog introduced Polly, the .NET resilience framework. This post builds on that knowledge to strengthen your application's interaction with API endpoints.
The original .NET
HttpClient was a convenient way to send and receive HTTP requests and responses on the web, but unless
HttpClient was carefully implemented its use could result in socket exhaustion. The release of .NET Core 2.1 introduced
HttpClientFactory, which can be instantiated once and used throughout the life of an application.
This post will show you how to combine
HttpClientFactory with Polly to achieve efficient and resilient service-to-service communications. You'll see how you can do it more reliably, conveniently, and with less code than using
To follow along ...
Service-to-service communication is becoming more and more common, but we know the network has never been reliable and that other people's code has bugs. Packets are lost, exceptions are thrown, and requests fail; it will happen to your application—to all applications!
Using the Polly Resilience Framework you can easily retry a failed request, no messy for loops or try catches needed. Just a few lines of code and your applications will never be the same!
This post shows how to make reliable requests to an unreliable "remote" service with almost no overhead.
You’ll start with a “remote” Web API application that returns errors 75% of the time. Then you’ll build a “local“ Web API application that calls the remote one (of course receiving errors three quarters of the time).
Finally, you will add Polly to the “local” application to perform retires on failed requests. With a few ...