Full Web Apps with FastAPI Transcripts
Chapter: Course conclusion and review
Lecture: async and await

Login or purchase this course to watch this video and the rest of the course contents.
0:00 We saw that to truly unlock FastAPI's massive,
0:03 massive scalability and performance, we have to make our view methods, our endpoints
0:08 async because when you have a web application, most of the time,
0:12 what is it doing? Its waiting on external things.
0:14 It's waiting on a queue, it's waiting on a database,
0:17 it's waiting on some microservice or external third party service.
0:21 All of that waiting can be completely put aside and allow your app to do other work,
0:26 maybe start other things that then in turn,
0:29 run awaits on those, right?
0:31 So most of a request is actually made up of waiting.
0:34 And if we have a synchronous web server like Flask,
0:37 like much of Django, like Pyramid and so on, the traditional WSGI applications, they don't have
0:42 this capability. So when a request comes in,
0:44 well, the first one gets processed right away,
0:47 and it takes as long as the expected time,
0:49 the green one. But because the server's busy, until we get done with Response 1
0:53 we can't start with 2,
0:54 it actually takes quite a bit longer and poor old fast little Response 3,
0:58 it's queued up, put behind in the line here for those two requests
1:01 So even though it's short,
1:03 it actually takes the longest of all three of these. We dive in,
1:07 we see the problem really is that we're mostly just waiting on other stuff, we're
1:11 like 80% weighting, 20% doing something computational on our end.
1:16 If we just rewrite this to
1:18 say await database query, await web service call and make our view methods
1:24 async, FastAPI will completely rework how it runs our code,
1:28 and it will process Request 2 while it's waiting on the database for 1.
1:32 And then it will be waiting on the database for 1 and 2 so it can
1:35 zip over, get Request 3 done really quick and then get back to waiting for
1:38 the others. And it really,
1:40 really amplifies the scalability. Now the scalability,
1:43 of course, depends on the scalability of the thing on the other end,
1:47 right? If you have a
1:48 database and the actual roadblock, was the database is really wimpy or it's poorly written without indexes
1:53 or something like that, eventually you're gonna hit a limit where just further down
1:57 the line, you're waiting on something else,
2:00 and it won't make it that much better.
2:01 But in a lot of cases where you have a fast database or external APIs
2:05 or many different services,
2:06 this is gonna see a huge improvement for your app.