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

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.

About Maarten Balliauw

Maarten Balliauw is a Developer Advocate at JetBrains, working on .NET tools. He focuses on .NET, Azure, web technologies and application performance. Maarten is a frequent speaker at various national and international events. In his free time, he brews his own beer. Follow him on Twitter or check his personal blog.
This entry was posted in How-To's and tagged , , , . Bookmark the permalink.

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

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

  2. Tom says:

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

  3. Parag says:

    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?

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

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

  5. Evgeny says:

    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

Leave a Reply

Your email address will not be published. Required fields are marked *