Best practices with HttpClient and Retry Policies with Polly in .NET Core 2, Part 1
- Best practices with HttpClient and Retry Policies with Polly in .NET Core 2, Part 1
- Best practices with HttpClient and Retry Policies with Polly in .NET Core 2, Part 2
Introduction
You probably have already needed to access remote data in your .NET Core application, especially through Http calls, with HttpClient. You remember ? certainly, but do you remember if you have consumed HttpClient correctly? I’m less sure about it.
Certainly like you, I made mistakes using them. These errors may have caused performance issues.
In this article I will explain how to use HttpClient correctly, but also how to make your application more robust by configuring a Retry Policy and a Circuit Breakdown with Polly.
What is Polly ?
Polly is a .NET resilience and transient-fault-handling library that allows developers to express policies such as Retry, Circuit Breaker, Timeout, Bulkhead Isolation, and Fallback in a fluent and thread-safe manner. From version 6.0.1, Polly targets .NET Standard 1.1 and 2.0+.
What’s a Retry Policy ?
Many faults are transient and may self-correct after a short delay. Then we would want to try again. A Policy Retry allows configuring automatic retries.
What’s a Circuit Breaker ?
When a system is seriously struggling, failing fast is better than making users/callers wait. Protecting a faulting system from overload can help it recover. A Circuit Breaker breaks the circuit (blocks executions) for a period, when faults exceed some pre-configured threshold.
Best practices with HttpClient
There are many ways to use HttpClient:
- Using HttpClient directly
- Using IHttpClientFactory
- Using Typed Clients (or Named Clients)
Using HttpClient
I never use HttpClient directly, I don’t recommand it, but if you want to use it directly (and with the well manner) I strongly suggest you to follow this guideline here that explains how to avoid performance issues with HttpClient:
http://farshidmirza.blogspot.com/2018/01/best-practices-for-using-httpclient-in-c.html
You can also check what happens when you don’t use correctly HttpClient: https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/
Using IHttpClientFactory
The good practice is to inject IHttpClientFactory by dependency in your services. You don’t need any configuration to inject for that in yout Startup class it’s built-in. IHttpClientFactory manages the pooling and lifetime of underlying HttpClientMessageHandler instances to avoid common DNS problems that occur when manually managing HttpClient lifetimes. Then it avoids performance issues.
Example of IHttpClientFactory usage:
Using Typed Clients (or Named Clients)
They provide a single location to configure and interact with a particular HttpClient. For example, a single typed client might be used for a single backend endpoint and encapsulate all logic dealing with that endpoint. Another advantage is that they work with DI and can be injected where required in your app. Behind a typed client there is IHttpClientFactory that manages HttpClient instances 😉 .
Always prefer a Typed Client instead of a Named Client because Intellisense is provided, for more information you can check Microsoft documentation here.
Example of Typed Client with its configuration in Startup.cs
So for these reasons I recommand to use typed clients. Because the single location we will be able to now to configure easily Retry Policies and Circuit Breakers with Polly 😉
