{"id":13,"date":"2024-02-09T06:25:29","date_gmt":"2024-02-09T06:25:29","guid":{"rendered":"https:\/\/denispavlov.net\/Blog\/?p=13"},"modified":"2024-03-20T07:12:08","modified_gmt":"2024-03-20T14:12:08","slug":"production-quality-httpclient","status":"publish","type":"post","link":"https:\/\/denispavlov.net\/Blog\/2024\/02\/09\/production-quality-httpclient\/","title":{"rendered":"Production Quality HttpClient"},"content":{"rendered":"\n

In this post I would like to discuss some of the good and bad ways to use the HttpClient<\/code>. I am going to start from the basics.<\/p>\n\n\n\n

What is the problem with the following code?<\/p>\n\n\n\n

public async Task<string?> GetContentAsync(string url)\n{\n    var client = new HttpClient();\n    var result = await client.GetStringAsync(url);\n    \n    return result;\n}<\/code><\/pre>\n\n\n\n
Problem is that the HttpClient<\/code> is not being properly disposed, as it implements IDisposable interface. So, let’s do it.<\/p>\n\n\n\n
public async Task<string?> GetContentAsync(string url)\n{\n    var client = new HttpClient();\n    var result = await client.GetStringAsync(url);\n    client.Dispose();\n\n    return result;\n}<\/code><\/pre>\n\n\n\n
Right? Well, not quite, because if GetStringAsync<\/code> throws an exception, we will not reach the dispose call. Let’s fix it.<\/p>\n\n\n\n
public async Task<string?> GetContentAsync(string url)\n{\n    var client = new HttpClient();\n    string? result;\n    \n    try\n    {\n        result = await client.GetStringAsync(url);\n    }\n    finally\n    {\n        client.Dispose();\n    }\n\n    return result;\n}<\/code><\/pre>\n\n\n\n
Since finally block will always execute, the client will get disposed. And shorthand code below actually achieves the same thing.<\/p>\n\n\n\n
public async Task<string?> GetContentAsync(string url)\n{\n    using var client = new HttpClient();\n    var result = await client.GetStringAsync(url);\n\n    return result;\n}<\/code><\/pre>\n\n\n\n
The using statement will take care of calling dispose when client is no longer in scope. So, are we good?<\/strong><\/p>\n\n\n\n
This is really beginning of what I wanted to discuss. The last code block is probably fine for Computer Science 101. However, in a production application where this method might be called thousands of times we will eventually get a nasty System.Net.Sockets.SocketException<\/code>. What’s worse is that it will probably pass all unit tests and QA process successfully.<\/p>\n\n\n\n
The problem is that when HttpClient<\/code> is disposed, the underlying sockets are not immediately released, leading to a situation where you may be creating HttpClients<\/code> faster than releasing all the resources, hence the exception. First thought might be to use a Singleton pattern on the HttpClient<\/code> so it is only initialized once and used throughout the application. However, there is an issue with that as well because your HttpClient<\/code> will not respond to DNS changes unless constructed correctly. So the recommended solution is dependency injection of HttpClientFactory<\/code>. Microsoft has good documentation on different ways of using the factory. My favorite pattern is the Typed client<\/a>.<\/p>\n\n\n\n
public class HttpService\n{\n    private readonly HttpClient _client;\n\n    public HttpService(HttpClient client)\n    {\n        _client = client;\n    }\n\n    public async Task<string?> GetContentAsync(string url)\n        => await _client.GetStringAsync(url);\n}<\/code><\/pre>\n\n\n\n
And register the service as follows.<\/p>\n\n\n\n
builder.Services.AddHttpClient<HttpService>();<\/code><\/pre>\n\n\n\n
We can also utilize Microsoft.Extensions.Http.Polly<\/code> to add some resiliency and exponential backoff on retries (as well as configure things like global message handlers, request headers and base URL on the client).<\/p>\n\n\n\n
var httpRetryPolicy = HttpPolicyExtensions\n    .HandleTransientHttpError()\n    .WaitAndRetryAsync(3, retryAttempt\n        => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)));\n\nbuilder.Services.AddHttpClient<HttpService>()\n    .AddPolicyHandler(httpRetryPolicy);<\/code><\/pre>\n\n\n\n
Voila! The above solution will avoid socket exhaustion and respond to DNS changes!<\/strong><\/p>\n\n\n\n
\n\n\n\n
However, sometimes the only option is to build an HTTP service without any dependencies that will be used as a Singleton. I’ve had this happen to me when I was asked to write a class library that integrates with a third party API, which would be consumed by legacy .NET Framework application written in VB.NET. Luckily, there is an alternative solution to achieve the same HttpClient<\/code> stability as above without using dependency injection and HttpClientFactory<\/code>.<\/p>\n\n\n\n