#100DaysOfWeb in Python Transcripts
Chapter: Days 21-24: Async Flask APIs with Quart
Lecture: Synchronous execution concepts
Login or
purchase this course
to watch this video and the rest of the course contents.
0:00
Before we start writing some code let's just think about what synchronous execution means and most importantly, what this looks like
0:09
and where the actual problem is in the first place. Because, until you run into a problem you should probably stick with synchronous code and Flask
0:17
or one of the other frameworks that we're talking about in this course, because asynchrony does add complexity. Let's understand the value of it
0:26
so you'll know when to use it and when not to use it. So, here we have particular web server and I'm trying to visualize
0:33
the processing time for various requests. Now, I said our first example was going to be straight
0:38
async code, but let's motivate this with a web example. So, here we have three requests coming to our server requests, one, two, and three.
0:46
Request one, takes as long as that green box. Label that. Request two takes about the same amount of time another big, fat green box.
0:54
And request three is really quick, but because the way the processing works, this just gets queued up our server just takes them in order.
1:01
Let's do one, okay, now we're done with that. Let's do two, now we're done with that. Let's do three, and so on. This is not so good.
1:09
Look how short three is. Wouldn't it be better if we could just get that answer to them right away? If we look at the actual response time.
1:16
So, when the request comes in, when it they actually, as far as the external client sees it when it's done, we can map that out as well.
1:25
So, the response gets sent back right away. So, for request one it's, they did the request same amount of time that it actually took us to do it
1:33
they get the response. But request two, well, their request came in right at that beginning of one
1:38
so they had to wait for one to be done, and then two. And three, this tiny little thing, actually was the worst. So, it had to wait for one and two
1:47
and then its little bit that it had to do. This is not ideal, but if you can make the size of those green boxes small enough
1:55
if they can outrun your traffic you don't need asynchronous programming. You're golden, right. Let's suppose you are getting a request
2:02
every 200 milliseconds to your server and it takes 20 milliseconds to process a request. You're fine, just synchronized programming.
2:10
But when things start to back up like this example here, well, that's a problem. So, how are we going to deal with that?
2:16
Let's look at one more thing before we actually get to code side of things. We take one of those green boxes
2:21
let's say request one, and we zoom into it. We look at actually what's happening. There's a bunch of different things operating here.
2:29
Probably right at the top, Flask, the framework is doing some processing, is running the routing figuring out what to call, it's creating and
2:36
initializing the request object, things like that. All that stuff's getting set up and then it comes and runs our code. The first thing our code does
2:43
let's say this is a purchase, for example. Somebody's going to come in. They're going to go and say, I'm user such and such.
2:51
So, our first time to do is say well, we're going to go to the database with their cookie, or their session, or something like that
2:57
query for their user object, and pull that back. So, that first part, that first read database that's us getting the user back.
3:04
Then we'd write a little code to say well, if we have this user and they're requesting this thing, let's find out if they own
3:10
this object, or maybe we want to show them a list of things, or whatever. So, we go back to the database with maybe one or more, queries, and that runs
3:18
and then we get a response. Maybe should be a little another blue box where we turn our response into something
3:23
we're sending back, but then we just send that back. The framework creates the response out of a template or something like that, or JSON
3:29
and returns it to the request. This is totally normal database code and there's not a problem with it per say however, look at this part here.
3:38
What is our code actually doing? It's just blocked on some database query just waiting, waiting on the network. If we send a request over the network
3:47
to the database server, it's got it, queued it up. Eventually it's going to compute the answer and send it back.
3:53
So, our code is just kind of sitting there not really doing anything except for waiting. So, the idea of the asynchronous programming is
4:01
these red sections, we can give up our execution time and hand that off to other requests like request two or three
4:10
while we're waiting on the database. We don't care. We're just waiting. So, if we could just wait and then be re-run
4:16
when the response comes back from the database it would be the same to us. So, that's the idea of this asynchronous of programming is.
4:22
We want to take these dead zones these waiting zones where we're waiting on external services, file system database, web services, things like that
4:31
and make them productive times for our code to do other stuff.