Flurl client lifetime in ASP.Net Core 2.1 and IHttpClientFactory

Question

Flurl states that using singleton client is recommended pattern:

HttpClient is intended to be instantiated once and re-used throughout the life of an application. Especially in server applications, creating a new HttpClient instance for every request will exhaust the number of sockets available under heavy loads. This will result in SocketException errors.

But since Asp.Net Core 2.1 there are updated rules for HttpClient lifetime in Net Core 2.1.

When you use the HttpClientFactory to request a HttpClient, you do in fact get a new instance each time, which means we don’t have to worry about mutating it’s state. This HttpClient may (or may not) use an existing HttpClientHandler from the pool and therefore use an existing open connection.

How to modify Flurl to use IHttpClientFactory under hood? Should I create custom Flurl's settings.HttpClientFactory and there create HttpClient through MS IHttpClientFactory?

Answer 1

First, it should be noted that MS's new HttpClientFactory is intended to be used in conjunction with ASP.NET Core 2.1 and its built-in DI container. If you're not injecting FlurlClients into controllers or service classes, and are instead using Flurl like this:

await url.GetJsonAsync();

then it's not even relevant. You should not implement Flurl's IHttpClientFactory to use MS's. It doesn't have the proper context to use the DI container and you'll end up resorting to service location, which is an anti-pattern. Those new socket pooling features you want to take advantage of actually live at a lower level:System.Net.Http.SocketsHttpHandler. Flurl uses HttpClientHander as its message handler by default, but luckily that's been rewritten in .NET Core 2.1 to defer all of its work to SocketsHttpHandler by default. In other words, if you're using Flurl in a .NET Core 2.1 app, you're already getting all the new socket management goodies that MS has been working on.

If you are using FlurlClient explicitly in an ASP.NET Core 2.1 app, as sort of a replacement for HttpClient, and would like to inject it into your classes while taking advantage of what MS's HttpClientFactory has to offer, I would suggest setting up HttpClientFactory in ConfigureServices exactly as prescribed by MS, and when you need a FlurlClient instance, use the constructor that takes an HttpClient instance. For example, when using the typed clients pattern, your service class might look like this:

public class MyService
{
    private readonly IFlurlClient _flurlClient;

    public MyService(HttpClient httpClient)
    {
        _flurlClient = new FlurlClient(httpClient);
    }
}