How-To's Webinars

Best Practices for Building Async APIs with ASP.NET Core – Webinar Recording

The recording of our January 22 webinar with Kevin Dockx is now available, as well as some resources and external links. Subscribe to our community newsletter to receive notifications about future webinars.

Did you know the main driver for async isn’t performance but scalability? Ever wondered why it makes sense to async I/O-bound tasks, but why doing the same with a long-running algorithm can actually hurt scalability? Or why using .Result on a Task in ASP.‌NET can result in a deadlock but perfectly works in ASP.‌NET Core – yet you still shouldn’t use it?

Webinar agenda:

  • 0:06 – Intro
  • 2:36 – Why write asynchronous code?
  • 15:12 – The async/await keywords
  • 20:20 – Async return types
  • 26:00 – Demo time
  • 42:30 – I/O bound vs. computational bound work
  • 57:40 – What about legacy code?
  • 1:01:16 – What about the synchronization context?
  • 1:22:20 – Wrap up and Q&A


About the presenter:

Kevin Dockx
Kevin is a freelance solution architect, Pluralsight author & consultant, living in Antwerp (Belgium). These days he’s mainly focused on RESTful architectures & security for web applications and mobile applications. He’s a Microsoft MVP, and a keen proponent of open-source software. Visit his blog at and follow him on Twitter.

Subscribe to our community newsletter to receive notifications about future webinars.

Comments below can no longer be edited.

6 Responses to Best Practices for Building Async APIs with ASP.NET Core – Webinar Recording

  1. Avatar

    Tom says:

    January 30, 2019

    In 59:30, he talks about “optimized threads”. What are those? Why is thread spawned by Task.Run() “unoptimized”?

    • Avatar

      Kevin Dockx says:

      February 12, 2019

      That should’ve read unoptimized thread SWITCH – sorry ’bout that 🙂

  2. Avatar

    Parag says:

    February 8, 2019

    When you say “Always use async keword on methods returning Task. The implementation should not leak in another layer” What does that really mean? And what could go wrong, as in what are the drawbacks of the same?

    • Avatar

      Maarten Balliauw says:

      February 12, 2019

      Just checked with Kevin:

      A Task represents the execution of an async method. Imagine you’re getting back a Task from somewhere deep inside your code from your repository. That allows you to follow the execution of whichever method deep inside your code the Task is related to – but the consumer of the repository doesn’t know which method that is. The consumer can act on the status of something that’s buried in a level of code the consumer doesn’t normally have access to. The consumer can even cancel that Task he shouldn’t have access to (eg: from another layer) – so that’s leaky code, imo. It’s a bit like exposing an IQueryable from a repository as far as “leakage level” (yes, I’m making up terms as we go along ;-)) is concerned. Moreover, it has another consequence: imagine that that repository method that returns a Task from somewhere in the code contains more than just a call into the method that returns the Task. This is pretty common for repositories that do more than just call into an EF context. By not allowing that method to be awaited, you’d also not allow that method to return its own Task (out of the box), which results in not being able to check the execution status of that method nor being able to cancel it. So it’s more than just code leakage.

      Just like you sometimes see repos that expose IQueryables, you’ll see repos or parts of code that expose Tasks that represent method execution of methods the consumer of the repo normally doesn’t have access to. I understand it can be convenient to code and maybe there’s even a use case that calls for code like this. But as a rule, I wouldn’t do that. Yet as we all know, especially in software architecture each rule can have exceptions and be diverted from as long as the consequences are understood. So far for my 2 cents 😉

  3. Avatar

    Evgeny says:

    February 15, 2019

    From presentation is not clear why no to increase size of thread pool

  4. Avatar

    Evgeny says:

    February 15, 2019

    About “async void” sounds a little over-adviced (about use only for events and only on client side). Infinitely running methods with async methods inside are good example of “async void” use on any side

Discover more