.Net framework async controllers
Hi, I need some help in understanding the pitfalls of async in .net framework.
Background
We have an old .mvc net framework application, we are in the process of migrating from mvc to a pure rest api. While doing so we are considering introducing mediator (the MediatR package). This has an async nature while the rest of our codebase is entirely sync. Are there any dangers of things like thread starvation by introducing this? Are there other pitfalls/dangers I should be vary of?
Example callstack before
1. Sync controller
2. Sync mediator (ish)
3. Synd db query
Example callstack after
1. Async controller
2. Async mediator
3. Sync db query
6 Replies
async over sync isn't dangerous, you're just getting less benefit by not having all of your IO async
sync over async is where you start running into problems
Thats what I also read online and felt pretty confident in, until my coworker starting questioning it. This is a "small" step in the right direction before we eventually start doing async db calls etc. But after reading online top down seems to be the best approach. As you are saying async over sync is unproblematic
The only pitfalls I can think of: 1) The code base starts to have both sync/async code, and you need all developers to be familiar with that and don't make trivial async mistakes. 2) Since the controllers become async and you remove the performance bottleneck there, something else might become the new bottleneck and you might see bad performance there. But again, nothing serious to worry about and you will be fine.
no dangers but there are dangers inherent to async; consider an analyzer like this to flag them up https://www.meziantou.net/enforcing-asynchronous-code-good-practices-using-a-roslyn-analyzer.htm
Meziantou's blog
Enforcing asynchronous code good practices using a Roslyn analyzer ...
In this post, I describe the Roslyn Analyzers that help writing good async/await code in .NET.
also, not a concern, just a bonus to keep in mind - as you use more async apis you will also have the opportunity to pass down CancellationTokens a lot more, so it can be worth passing those down the chain to your database layer preemptively, even if you don't use the async db calls just yet
your controllers can have cancellationtokens at the top level for when users kill their requests early
Thank you all for responding, I will definitely read up on the analyzer. Very good tip with the cancellation tokens. The whole thing is a temporary facade until I can start calling async services so the more "realistic" it is the better