Build the future of communications.
Start building for free
  • By Bryan Hogan
    More Resilient Service-to-Service Communication with Polly and .NET HttpClientFactory Copy of Generic Blog Header 4.png

    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 HttpClient.

    Prerequisites

    To follow along ...

    Read More
  • By Bryan Hogan
    Building Resilient Service-to-Service Communications in ASP.NET Core with Polly, the .NET Resilience Framework rwNecMwoSUez0Ube7w9hsk4xKt_AVXOmIPDyu8qHhgvjZZUDl2t5hQyMp0YIclb6XpIdKdRSFRVnhg0Tf78mV7SmPFSWHGpkGMUzF68JTo2D40YC1VlT-auZj3qg-5Ub40shcDCu

    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 ...

    Read More
  • Newer
    Older
    Sign up and start building
    Not ready yet? Talk to an expert.