CODEWITHSUNDEEP
c#restasync-await
BaptisteL
BaptisteL

Reputation: 113

Is async all the way inevitable for C# rest API?

I saw and read a lot of pages about async-await in C# but something is still unclear. With a 3-Tier architecture like Controller - Business Layer - Data Layer, if your Data Layer do async method (because its calling Database or RestAPI), your Business Layer and Controller need to be async and await too. This is a design intent ?

I understand that async-await is usefull for call that are not handled by the server CPU like for database call or http calls, then you can give the current thread to another task and return to this one when the async operation is finished. But with an architecture like I explained, if you have async method in your lowest layer you endup bubbling up the async-await pattern everywhere and it seems that it's not useful in those cases.

I must be missing something or some explanation. So you know I read multiple thread on stackoverflow and some Microsoft documentation but still can't explain that.

Upvotes: 2

Views: 540

Answers (1)

Flater
Flater

Reputation: 13783

Let's invert the example. Compare a regular synchronous application, and and application which is internally async but wrapped in a synchronous shell. How would they appear different to the outside observer?

They wouldn't. Sure, you may know that in your application it's a different component that is blocking the thread (e.g. BLL instead of DAL); but the outside observer only cares that there is a thread being blocked, not which object or layer in the application is doing it. The outside observer pretty much by definition does not care nor differentiate between the internal implementations of an application.

The only way for an application to not block the thread, which is the core principle of asynchrony; is for the await logic to bubble up out of your application. Now, the outside observer sees a difference: the thread isn't blocked and the observer is able to go do something else in the meanwhile. Without that being the case, there is no point to having asynchrony in the first place.

At its very core, synchronous code does not communicate. You give your employee a job: heat the sauce. He uses a microwave. It takes him 10 seconds to put it in and 10 seconds to take it out. During the microwaving, he either stands there doing nothing or leaves the kitchen and tells no one. Others are waiting to use the kitchen, and he's not doing anything and is therefore wasting kitchen availability because he never told anyone that they could jump in while he was waiting for the microwave. He's blocking the path in the kitchen for no purpose other than because he chose to idle there. This is a synchronous worker.

Comparatively, an asynchronous worker will realize that he is idling, steps out of the kitchen to make way, and lets the others know that there is now space for them to get their own work done in the kitchen.

But the only way in which this works is if he actually tells the others that he has stepped out of the kitchen so that they can get in. This part of the analogy is the equivalent of having your await logic bubble up out of your application. If you keep it inside, then you've not communicated.

One more thing: if your application starts a task, but has enough other work to do while the task completes; when it finally awaits the (already finished by now) task, it never bubbled up out of your application. An await only bubbles up if the thread has nothing more to do except waiting.

Upvotes: 3

Related Questions