MNW #041: Scheduling Background Jobs With Quartz.NET

Read time: 5 minutes

A big thank you to our sponsors who keep this newsletter free to the reader:

Today's issue is sponsored by Fiverr. Fiverr is your one-stop solution for finding skilled freelance developers. Build custom APIs and integrations tailored to your needs. Seamlessly connect with payment providers (Stripe, PayPal) and automation platforms (Zapier) for streamlined operations. Check it out here!

And by Treblle. Treblle is a lightweight SDK that helps engineering and product teams build, ship & maintain REST-based APIs faster. Simple integration for all popular languages & frameworks, including .NET 6.

If you're building a .NET application, chances are high that you'll need to call an external API over HTTP.

The easy way to make HTTP requests in .NET is to use the HttpClient to send those requests. And it's a great abstraction to work with, especially with the methods supporting JSON payloads and responses.

Unfortunately, it's easy to misuse the HttpClient.

Port exhaustion and DNS behavior are some of the most common problems.

So here's what you need to know about working with HttpClient:

How not to use HttpClient
How to simplify configuration with IHttpClientFactory
How to configure typed clients
Why you should avoid typed clients in singleton services
When to use which option

Let's dive in.

The Naive Way To Use HttpClient

The simplest way to work with the HttpClient is to just create a new instance, set the required properties and use it to send requests.

What could possibly go wrong?

HttpClient instances are meant to be long-lived, and reused throughout the lifetime of the application.

Each instance uses it's own connection pool for isolation purposes, but also to prevent port exhaustion. If a server is under high load, and your application is constantly creating new connections, it could lead to exhausting the availabale ports. This will cause an exception at runtime, when trying to send a request.

So how can you avoid this?

The Smart Way To Create HttpClient Using IHttpClientFactory

Instead of managing the HttpClient lifetime yourself, you can use an IHttpClientFactory to create the HttpClient instance.

Simply call the CreateClient method and use the returned HttpClient instance to send your HTTP requests.

Why is this a better approach?

The expensive part of the HttpClient is the actual message handler - HttpMessageHandler. Each HttpMessageHandler has an internal HTTP connection pool that can be reused.

The IHttpClientFactory will cache the HttpMessageHandler and reuse it when creating a new HttpClient instance.

An important note here is that HttpClient instances created by IHttpClientFactory are meant to be short-lived.

Reducing Code Duplication With Named Clients

Using IHttpClientFactory will solve most of the issues of manually creating an HttpClient. However, we still need to configure the default request parameters every time we obtain a new HttpClient from the CreateClient method.

You can configure a named client by calling the AddHttpClient method and passing in the desired name. The AddHttpClient accepts a delegate that you can use to configure the default parameters on the HttpClient instance.

The main difference is you now have to obtain the client by passing the name of the client to CreateClient.

But the use of the HttpClient looks a lot simpler:

Replacing Named Clients With Typed Clients

The downside of using named clients is having to resolve an HttpClient by passing in a name every time.

There's a better way to achieve the same behavior by configuring a typed client. You can do this by calling the AddClient<TClient> method and configuring the service that will consume the HttpClient.

Under the hood, this is still using a named client, where the name is the same as the type name.

And this will also register GitHubService with a transient lifetime.

Inside of GitHubService, you inject and use the typed HttpClient instance which will have all of the configuration applied.

No more dealing with IHttpClientFactory and creating HttpClient instances manually.

Why You Should Avoid Typed Clients In Singleton Services

You could run into a problem if you inject a typed client into a singleton service. Since the typed client is transient, injecting it in a singleton service will cause it to be cached for the lifetime of the singleton service.

This will prevent the typed client from reacting to DNS changes.

If you want to use a typed client in a singleton service, the recommened approach is using SocketsHttpHandler as the primary handler, and configuring the PooledConnectionLifetime.

Since the SocketsHttpHandler will handle connection pooling, you can disable recycling at the IHttpClientFactory level by setting HandlerLifetime to Timeout.InfiniteTimeSpan.

When Should You Use Which Option?

I showed you a few possible options for working with HttpClient.

But which one should you use and when?

Microsoft was kind enough to provide us with a set of best practices and recommended use for HttpClient.

Use a static or singleton HttpClient instance with a PooledConnectionLifetime configured, since this solves both port exhaustion and tracking DNS changes
Use IHttpClientFactory if you want to move the configuration to one place, but remember that clients are meant to be short-lived
Use a typed client if you want the IHttpClientFactory configurability

I prefer working with a typed client, and I'm mindful of the fact that it's configured as a transient service.

Thanks for reading, and have an awesome Saturday.

Whenever you're ready, there are 2 ways I can help you 🎁

If you're looking to join a community of like-minded engineers or you want to access all of the source code that I use in my YouTube videos, you can do that by becoming a Patron. Join 720+ engineers here.
Promote yourself to 22,000+ subscribers by sponsoring this newsletter (booked out 2 months)

You received this email because you subscribed to our list. You can unsubscribe at any time.

Dragise Cvetkovica 2, Niš, 18000, Serbia

MNW #041: The Right Way To Use HttpClient In .NET

MNW #041: Scheduling Background Jobs With Quartz.NET

The Naive Way To Use HttpClient

The Smart Way To Create HttpClient Using IHttpClientFactory

Reducing Code Duplication With Named Clients

Replacing Named Clients With Typed Clients

Why You Should Avoid Typed Clients In Singleton Services

When Should You Use Which Option?

Older messages

MNW #040: Scheduling Background Jobs With Quartz.NET

MNW #039: Build a CI/CD Pipeline With GitHub Actions And .NET

MNW #038: Multi-Tenant Applications With EF Core

MNW #037: Visualize Your Software Architecture With The C4 Model

MNW #036: Enforcing Software Architecture Rules With Architecture Tests

You Might Also Like

Daily Coding Problem: Problem #1668 [Easy]

Django vs FastAPI, Interacting With Python, Data Cleaning, and More

🤖 Yes, I Do Want a Drink-Carrying Robot — The Best Way to Give Old TVs Bluetooth

Charted | AI's Perceived Impact on Job Creation, by Country 🔮

HackerNoon Decoded: How Users Searched in 2024

Hack Your Python Roadblocks -- Just 5 Seats Left

Spyglass Dispatch: TikTok & Twitter

5 AI Predictions for 2025 (AI hype dying; real opportunities rising)

Power BI Weekly #291 - 14th January 2025

LW 165 - How Shopify Built Its Live Globe for Black Friday