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?
HttpClientFactory. For advanced scenarios, you can customize the way Flurl. Http constructs HttpClient and HttpMessageHandler instances. Although it is only required that your custom factory implements Flurl.
In general, HttpClientHandler can be used to configure a specific configuration like custom policy, headers, or security mechanism, compression, certificates, etc. We shall cover the below aspects in this article, Configure HttpClientHandler for Authentication Example: Bearer or Basic.
IHttpClientFactory is a contract implemented by DefaultHttpClientFactory , an opinionated factory, available since . NET Core 2.1, for creating HttpClient instances to be used in your applications.
In the preceding code, AddHttpClient registers GitHubService as a transient service. This registration uses a factory method to: Create an instance of HttpClient .
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 FlurlClient
s 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);
}
}
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With