Effectively use async await with ASP NET Web API

Question

I am trying to make use of the async await feature of ASP NET in my Web API project  I am not very sure whether it will make any difference in performance of my Web API service  Please find below the workflow and sample code from my application   Work Flow   UI Application   Web API endpoint controller    Call method in Web API service layer   Call another external web service   Here we have the DB interactions  etc    Controller   public async Task lt IHttpActionResult gt  GetCountries         var allCountrys   await CountryDataService ReturnAllCountries         if  allCountrys Success                return Ok allCountrys Domain              return InternalServerError        Service Layer   public Task lt BackOfficeResponse lt List lt Country gt  gt  gt  ReturnAllCountries         var response    service Process lt List lt Country gt  gt  BackOfficeEndpoint CountryEndpoint   returnCountries         return Task FromResult response       I tested the above code and is working  But I am not sure whether it is the correct usage of async await  Please share your thoughts

User · Accepted Answer

I am not very sure whether it will make any difference in performance of my API.

Bear in mind that the primary benefit of asynchronous code on the server side is scalability. It won't magically make your requests run faster. I cover several "should I use async" considerations in my article on async ASP.NET.

I think your use case (calling other APIs) is well-suited for asynchronous code, just bear in mind that "asynchronous" does not mean "faster". The best approach is to first make your UI responsive and asynchronous; this will make your app feel faster even if it's slightly slower.

As far as the code goes, this is not asynchronous:

public Task<BackOfficeResponse<List<Country>>> ReturnAllCountries()
{
  var response = _service.Process<List<Country>>(BackOfficeEndpoint.CountryEndpoint, "returnCountries");
  return Task.FromResult(response);
}

You'd need a truly asynchronous implementation to get the scalability benefits of async:

public async Task<BackOfficeResponse<List<Country>>> ReturnAllCountriesAsync()
{
  return await _service.ProcessAsync<List<Country>>(BackOfficeEndpoint.CountryEndpoint, "returnCountries");
}

Or (if your logic in this method really is just a pass-through):

public Task<BackOfficeResponse<List<Country>>> ReturnAllCountriesAsync()
{
  return _service.ProcessAsync<List<Country>>(BackOfficeEndpoint.CountryEndpoint, "returnCountries");
}

Note that it's easier to work from the "inside out" rather than the "outside in" like this. In other words, don't start with an asynchronous controller action and then force downstream methods to be asynchronous. Instead, identify the naturally asynchronous operations (calling external APIs, database queries, etc), and make those asynchronous at the lowest level first (Service.ProcessAsync). Then let the async trickle up, making your controller actions asynchronous as the last step.

And under no circumstances should you use Task.Run in this scenario.

User · Answer

I would change your service layer to   public Task lt BackOfficeResponse lt List lt Country gt  gt  gt  ReturnAllCountries         return Task Run      gt                return  service Process lt List lt Country gt  gt  BackOfficeEndpoint CountryEndpoint   returnCountries                    as you have it  you are still running your  service Process call synchronously  and gaining very little or no benefit from awaiting it   With this approach  you are wrapping the potentially slow call in a Task  starting it  and returning it to be awaited   Now you get the benefit of awaiting the Task

User · Answer

You are not leveraging async   await effectively because the request thread will be blocked while executing the synchronous method ReturnAllCountries    The thread that is assigned to handle a request will be idly waiting while ReturnAllCountries   does it s work    If you can implement ReturnAllCountries   to be asynchronous  then you would see scalability benefits  This is because the thread could be released back to the  NET thread pool to handle another request  while ReturnAllCountries   is executing  This would allow your service to have higher throughput  by utilizing threads more efficiently

User · Answer

It is correct  but perhaps not useful   As there is nothing to wait on     no calls to blocking APIs which could operate asynchronously     then you are setting up structures to track asynchronous operation  which has overhead  but then not making use of that capability   For example  if the service layer was performing DB operations with Entity Framework which supports asynchronous calls   public Task lt BackOfficeResponse lt List lt Country gt  gt  gt  ReturnAllCountries         using  db   myDBContext Get            var list   await db Countries Where condition  ToListAsync            return list            You would allow the worker thread to do something else while the db was queried  and thus able to process another request    Await tends to be something that needs to go all the way down  it is very hard to retro-fit into an existing system

[c#] Effectively use async/await with ASP.NET Web API

Examples related to c#

Examples related to asp.net-mvc

Examples related to asp.net-web-api

Examples related to async-await