![]() ![]() The logic related to the typed client is in a typed client’s class and our service is just calling that method. With this method, we fetch the companies from the API and return a result.įinally, we can modify the GetCompaniesWithTypedClientmethod in a service class: private async Task GetCompaniesWithTypedClient() => await _companiesClient.GetCompanies() Using (var response = await _client.GetAsync("companies", HttpCompletionOption.ResponseHeadersRead)) NET/C# content and get paid? > JOIN US! > GetCompanies() Wanna join Code Maze Team, help us produce more awesome. To do that, we are going to modify the CompaniesClient class: Since we already have the typed client class, we can extract all the related logic from the service to this class. Encapsulation of the Logic Related to a Typed Client Now let’s see how to extract the company related logic to the CompaniesClient class. Once we start both applications, we are going to get the same result as before: await GetCompaniesWithHttpClientFactory() This time, we just use the injected typed client with its Client property.įinally, let’s just execute this method: public async Task Execute() Var companies = await JsonSerializer.DeserializeAsync>(stream, _options) Īs we can see, we are not creating a new client instance by using the CreateClient method. Using (var response = await _("companies", HttpCompletionOption.ResponseHeadersRead)) Then, we are going to create a new method to make use of our typed client: private async Task GetCompaniesWithTypedClient() Public HttpClientFactoryService(IHttpClientFactory httpClientFactory) Private readonly JsonSerializerOptions _options Private readonly IHttpClientFactory _httpClientFactory Now, let’s create a new service class as we did in our previous articles: public class HttpClientFactoryService : IHttpClientServiceImplementation We are going to expand this method with additional configuration soon enough. NET/C# content and get paid? > JOIN US! () įor now, this is enough. When we use a new message handler, we take all the DNS changes into account. Well, with that, we solve the DNS issues. This means we don’t have to create a new message handler for every request and also we don’t have to open a new connection, thus preventing the socket exhausting issue.įurthermore, since the handler’s lifetime is set to two minutes, after that time, HttpClientFactory uses a new message handler. The default lifetime of a handler is set to two minutes, and during that time, any request for a new HttpClient can reuse an existing message handler and the connection as well. Then, it uses that message handler to send the requests to the API. Basically, when creating new HttpClient instances, it doesn’t recreate a new message handler but it takes one from a pool. Not only that HttpClientFactory can create and manage new HttpClient instances but also, it works with underlying handlers. How HttpClientFactory Helps Us Solve Mentioned Problems? To help us solve these problems, we can use HttpClientFactory to create HttpClient instances. If our connection is not aware of switching from staging to the production environment, our requests would not go to the right environment as well. Thus connections won’t get the update from DNS (for example switching between different environments). When we reuse our instance, we also reuse the connection until the socket is closed. This also allows reusing of the underlying connections.īut, we have to pay attention, that using a static instance is not the ultimate solution. That’s what we’ve been doing in our previous articles with the static HttpClient instance. So, with all these in mind, we can conclude that we shouldn’t dispose of our HttpClient but share it throughout the requests. By creating too many connections, we can face socket exhaustion because we use too many sockets too fast, and we don’t have any available socket to create a new connection. Reopening connections could lead to slow performance because these connections and HttpClientHandlers are pretty expensive while working with HttpClient.Īlso, there is another problem. Now, this means that for every new request we have to create a new HttpClient instance and thus the handler as well. If we dispose of the HttpClient, we are going to dispose of the underlying HttpClientHandler as well. By seeing that, we can all be tempted to try using our HttpClient instance inside the using directive, thus disposing of it once it is out of the scope. The HttpClient class implements the IDisposable interface. You can also visit our HttpClient Tutorial page, to see all the articles from this tutorial. To download a source code, you can visit our HttpClientFactory repository.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |