Best practices on using IHttpClientFactory

[rafalkwol]

Hello,

I have been wondering lately how to properly use the IHttpClientFactory to avoid opening too many sockets and reaching sockets exhaustion. Let me give you an idea of what I'm not sure about. I have an ASP.NET Core WebAPI with multiple Controllers (for now around 20). And I also have an .NET Core WinForms application which uses this WebAPI to handle it's functionallity. At the moment I use the Refit library to create API Clients combined with IHttpClientFactory. For the sake of utility I split my typed HttpClients for every controller so at the moment I have in total 20 different services that communicate with the WebAPI and all of them are registered in IHttpClientFactory as separate typed client. All of them connect to the same IP address just to different routes/endpoints depending on the Controller. My question is - does IHttpClientFactory somehow "know" that all those different services are connecting to the same IP and resue the connection or does it create a separate pool of those for each typed client? As I think my WebAPI will only grow in size and more Controllers will be there so I'm wondering if this approach won't lead to increasing number of concurrent connections.

[LeaFrock]

I split my typed HttpClients for every controller

I think you misunderstand IHttpClientFactory and HttpClient. A simple answer is 'One target host, one typed HttpClient'. Since your Web-API app will be hosted as a single application with one distributed IP&Port, you just need to create one typed client with IHttpClientFactory and let it communicate with the backend.

[rafalkwol]

Since my post I implemented a solution where all the typed clients from Refit now share one HttpClient if they are related to the same WebAPI so I managed to keep the utility of having separate clients per controller, but now with shared underlying HttpClient so the issue is now solved I think and the potential socket exhaustion shouldn't affect me anymore. Thanks for the input.