{"id":1560,"date":"2020-08-19T09:00:40","date_gmt":"2020-08-19T16:00:40","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cosmosdb\/?p=1560"},"modified":"2020-08-31T10:33:38","modified_gmt":"2020-08-31T17:33:38","slug":"httpclientfactory-cosmos-db-net-sdk","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cosmosdb\/httpclientfactory-cosmos-db-net-sdk\/","title":{"rendered":"HttpClientFactory in the Azure Cosmos DB .NET SDK"},"content":{"rendered":"

You might already be familiar (and if not, you should) with this famous post called “You’re using HttpClient wrong<\/a>” and how it is important to reuse connections across the lifetime of your application. Recently, the V3 .NET SDK has added a feature called HttpClientFactory<\/strong> as part of the CosmosClientOptions<\/a>, which is used to customize the client instance and enables HTTP connection sharing between the SDK client and other clients within the same application. How? Let’s see!<\/p>\n

First things first<\/h3>\n

If you are reading this post, you either detected a scenario where your application is using a lot of connections (and it’s causing issues on your environment), or you are trying to optimize because, well, we all like when things are tidier.<\/p>\n

So the first thing you need to verify is that you only have one SDK client for the entire lifetime of the application<\/strong>. Dependency Injection frameworks make this very easy these days, if you use ASP.NET Core<\/a> for example, it’s as simple as registering it when configuring your services:<\/p>\n

https:\/\/gist.github.com\/ealsur\/ea583996ec32ee0cbcc4683db6c3b42a<\/p>\n

If you don’t use Dependency Injection frameworks, you could opt for having static variables. Just make sure that whatever you do, there is only a single instance (be careful with Repository Patterns that create client instances internally!).<\/p>\n

This sounds similar to IHttpClientFactory in .NET<\/h3>\n

And the reason for that is because the HttpClientFactory feature was initially designed to work alongside the IHttpClientFactory provided by ASP.NET Core<\/a>. This allows the application to centralize the creation of HttpClients and, therefore, allow consumers to reuse already existing connections.\u00a0<\/p>\n

When designing the feature, we aligned it with the IHttpClientFactory.CreateClient<\/a> method, to make it easier for developers to leverage.<\/p>\n

https:\/\/gist.github.com\/ealsur\/491bbbe78e5349d6f0ff3bb3fd051515<\/p>\n

Blazor Wasm support<\/h3>\n

In Blazor Wasm applications, HTTP requests are handled by the browser<\/a>, that is why the recommendation is to leverage IHttpClientFactory<\/a>. With the below code, we are wiring the SDK client to use the browser for all its data transport operations:<\/p>\n

https:\/\/gist.github.com\/ealsur\/d435fe063469fe09235e6d9e9eb81315<\/p>\n

 <\/p>\n

It’s important to switch to Gateway mode<\/strong> because Blazor Wasm\u00a0 does not support TCP connections.<\/p>\n

Sharing HttpClients<\/h3>\n

What if your application uses the SDK client, but also other HttpClients (maybe you do calls to a REST API), or have other service clients that also use HttpClient, or you are using Resource Tokens to authenticate<\/a> with Cosmos DB?<\/p>\n

In those cases, instead of using the IHttpClientFactory, you create new HttpClient instances for each service that needs it, but reuse a SocketsHttpHandler instance<\/strong> for all of them.<\/p>\n

https:\/\/gist.github.com\/ealsur\/87103ca1ccc10b16bde2d44483a937ce<\/p>\n

There are two keys here:<\/p>\n