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