CODEWITHSUNDEEP
c#asp.net-core.net-coreasync-await
Urs Meili
Urs Meili

Reputation: 809

dotnet.core Asp.net Async / await everywhere?

I recently began working in a new company. They have an ASP.NET Core 3.1 application hosted in IIS, which takes API calls from an angular app. They used async/await literally "everywhere": Methods in the ASP.NET controllers have signatures like public async Task<IActionResult> Foo(), all DB queries are made async, all calls to external APIs anyways (which I kind of understand).

So instead of simply

[HttpPost("api/ignorableDepartment")]
public IActionResult Add([FromBody] AddIgnorableDepartmentRequest model)
{
  return _ignorableGroupManager
          .Add(model)
          .ToResult();
}

the code now reads

[HttpPost("api/ignorableDepartment")]
public async Task<IActionResult> AddAsync([FromBody] AddIgnorableDepartmentRequest model)
{
    return await _ignorableGroupManager
                 .AddAsync(model)
                 .ToResultAsync()
                 .ConfigureAwait(false);
}

This application is only used by 1-2 people at the same time, and the calls in the method above would take 1ms at most.

In the past I would only use async/await if the processing is expected to last like 1 second or more, and in all other cases, I would just rely on IIS to take care of spreading multiple requests across threads/cores.

Did I just miss something in the past years, and this is the new way to develop? Or is that just overkill?

Updated information to answer questions in the comments

public static async Task<IActionResult> ToResultAsync(this Task task)
{
    if (task == null)
    {
        throw new ArgumentNullException(nameof(task));
    }

    await task.ConfigureAwait(false);
    return new OkObjectResult(ResultResponse.Success);
}

Upvotes: 1

Views: 1151

Answers (2)

Stephen Cleary
Stephen Cleary

Reputation: 456437

the calls in the method above would take 1ms at most.

In the past I would only use async/await if the processing is expected to last like 1 second or more

I think this is a misunderstanding here. "Asynchronous" does not mean "faster". Actually, because asynchronous requests have more bookkeeping work to do, asynchronous requests are actually (a tiny, tiny bit) slower.

Asynchrony in ASP.NET is all about scalability. Asynchronous requests free up more threads so that the server can handle more requests at the same time.

This application is only used by 1-2 people at the same time

So you're saying the application doesn't need to scale. Which is the primary benefit of asynchrony on ASP.NET.

Did I just miss something in the past years, and this is the new way to develop? Or is that just overkill?

There's a few different scenarios to consider.

One scenario is when you're writing new code. If you're writing new code (or a new app), then everything is asynchronous by default, and I'd argue that that's good. Perhaps the application will need to scale in the future. Or move to the cloud, where the pay-per-use model means asynchronous apps are often cheaper. Generally speaking, new apps should be asynchronous from the start.

Another scenario is when you have a synchronous app and you want to determine whether it's worth it to change it to be asynchronous. In this case, you have to evaluate the necessary scalability and future directions of the application, and make a judgement call on whether it's worth the developer time or not.

Upvotes: 5

Dobromir Ivanov
Dobromir Ivanov

Reputation: 439

Yes this is the best practice of doing it.

I guess your colleagues are just used to do it this way, no matter how heavy the application is loaded.

It is a good practice! We are also doing it.

The point is if in some of the endpoints you want to do some relatively heavy operation (let's say more than 1-2 seconds), by using async/await you can free the thread to go and do some extra work instead of waiting. It is a performance gain in most cases,

So I recommend you to get used to it and start doing it.

Upvotes: -2

Related Questions