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

Maarten Balliauw

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?

https://youtu.be/_T3kvAxAPpQ

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

Resources:

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 KevinDockx.com and follow him on Twitter.

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

Comments below can no longer be edited.

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

  1. Dew Drop – January 24, 2019 (#2884) | Morning Dew says:

    January 24, 2019

    […] Best Practices for Building Async APIs with ASP.NET Core – Webinar Recording (Maarten Balliauw) […]

  2. Tom says:

    January 30, 2019

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

    • Kevin Dockx says:

      February 12, 2019

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

  3. 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?

    • 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 😉

  4. Evgeny says:

    February 15, 2019

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

  5. 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

Subscribe

Subscribe to .NET Tools updates