The Right Way To Build Async APIs in ASP.NET Core

Learn how to properly implement asynchronous APIs in ASP.NET Core to maximize performance and efficiency. This video covers best practices for async APIs, common pitfalls to avoid, and proven techniques to make your APIs faster and more scalable. We'll dive into real-world examples demonstrating how to structure your async code correctly, with practical tips for handling concurrent requests and managing server resources effectively. Whether you're new to async programming or looking to optimize your existing APIs, you'll learn the right way to implement asynchronous operations in your ASP.NET Core APIs.

Building Async APIs in ASP.NET Core - The Right Way

Check out my courses:

Read my Blog here:

Join my weekly .NET newsletter:

Chapters
0:00 The Problem
3:05 Background processing delay
4:25 Async APIs with Channel
7:55 Tracking background job status
8:51 Building Async APIs
10:54 Adding the status endpoint
13:43 Creating the background worker
16:38 Testing our Async API

[macmcmillen]

This is really cool and helpful. Where I work, we have a mobile app that sends photos to .NET 8 Web API which does some light processing and then sends those photos to Azure blob storage. Currently, the mobile app waits for all that work on the backend to complete before it is able to do other tasks. Using the approach in this video would drastically better the mobile app user experience. Thanks for this, Milan.

[minimalstory]

videos have started to come out more often and I'm glad about it

[shahzadazzam]

I’ve started watching your videos almost every day and learning something new each time. Thank you for consistently sharing such valuable content!

[GabrielSoldani]

There’s a tricky race condition here. Since you set the statusDictionary[id] to Queued after awaiting the write into the channel, there’s always a chance that the background job will immediately pick it up and start processing it before the await returns. Worst case scenario, the background job finishes processing _before_ statusDictionary[id] is set to Queued and you end up with jobs that look like they never finish.

[TurgayTuerk]

I’ve always been curious about how such business scenarios are tackled using APIs. Thank you for the excellent introduction to 'Asynchronous Processing' with channels—it was both insightful and practical! Would it be possible to create a video demonstrating a similar scenario, but this time using webhooks in an event-driven approach?

[vekzdran]

Anon type supports with!? Hah, worth a watch just to learn about this! Great work!

[jamaicantillidie]

This was just what I needed. Creating a sms text twlio client and this works for me.

[RMarjanovic]

Ee, o ovome smo pričali. Super da si stigao na ovu temu :D

[zakraw]

Nice share! It's not scalable approach but in most cases we don't need Kafka or RabbitMQ for everything.

[Kingside]

Thank you Milan for providing such usefull Videos!
Only one think I would suggest is return status (enum) not as number but rather as string.
The consumer do not know the number behind the status. I know ASP convert enums to numbers but this is bad in my opinion.

[TheEngineerGuy-TEG]

This is very helpful, but in real-world scenarios, we often face constraints such as not being able to modify the existing endpoint response while still needing to optimize performance.

[pixelpanda]

Hey Milan, quick question. Are you planning on integrating Aspire into your Modular Monolith course or is it going to be a separate course?

[eminovperviz]

If you are in a situation that is forcing you to use asynchronous services or asynchronous messaging it means that you have great traffic. Then, of course you need to scale your app. If you will scale your app this implementation will not work for you. Because .net channels work in-memory and it means that if you have multiple instances you will get the same requests processed twice or more.

Summary: be careful to use this implementation if you will use it in multiple instance scenarios

[rey]

Using channels is nice, but personally, I don’t think this is the best use case. The state will be lost if the instance is restarted while processing. I would personally use the database to store the messages and have a background job poll the database for changes and do the processing instead.

I would use a channel to process some messages that have been read from the database, distribute the messages to different readers, and eventually mark the database entry as stale once done. In such a case, even if the instance is restarted, I will still read the same message again and finalize the work. That being said, I think this example fairly well explains how a channel can be used, but one has to be careful with its caveats. Thanks for the video.

[CezarLamann]

Hi Milan. For the background job service, don't we need to recreate the scope from the DI container to use scoped services?

Thank you, and this is a nice video as always.

[volt]

Nice video. I was thinking of async apis and what's the best way to implement one. Take aside background processing and how it is implemented, and let's think about client and how it consumes the response. Polling? - might send too many unnecessary requests to server. SignalR? - will not produce additional requests and notify client on job completed but requires duplex server-client connection which seems overwhelming in this case. So another one which could be used is SSE which eliminates cons of those two approaches and just notifies client. But I'd like to hear someone else's opinion on this...

[pauljacobson]

Thanks for your video, I didn't know about channels.

Is the mechanism you implement here similar to hangfire?

[juancarlosrodriguez]

sumamente interesante, no sabía nada de lo descrito

[ruekkart]

What about using SignalR to send back a response whenever it is ready instead of polling?

[enkiea]

Would be useful if you could somehow post a link to the source to a full simple solution. Especially when the link to your blog post on the subject is slightly different. (in case we miss an important line in the video and don't do the code quite right and spend a long time troubleshooting) Thanks