WSGI & ASGI Simplified

hello everyone welcome to my channel today we will be looking at two terms that you must have seen when working with python web frameworks in the case of django and flask you must have heard about web server gateway interface also known as wsgi and for fast api you must have heard about asynchronous server gateway interface also known as asgi but what are they let's find out as the name suggests both of them are gateway interfaces they stand in between the outside world and the web application and handles the request from the clients the difference between wsgi and asgi is in the way the requests are handled now explain the difference using an example of making breakfast i want to make a breakfast that includes tea and omelette i will first make tea and then omelette i will do everything in sequential order so i'll get the milk from the fridge get the tea powder sugar from cupboard i'll then warm the milk and add tea powder to milk then i'll add sugar to milk and then pour it in the cup so my tea is ready then i'll go on to make the omelet i'll get the egg from the fridge i'll get frying pan oil and spatula from the cupboard i'll light the stove i'll pour oil to pan for egg to pan i will then pick the omelet using the spatula and put it in the plate this is the same process followed by wsgi you get the request from your client that points to a function or a class which then has lines of code each line of code is executed sequentially and finally the response is provided to the client the application then handles the next request and follows the same process until the response is provided to the client so wait does that mean that the web application as a whole handle only one request at a time no that's where workers come into the picture when deploying applications built on django or flask you must have specified the number of workers that would handle request this is done in wsci servers such as kunicorn these workers handle multiple requests from clients at a time going back to the analogy of making breakfast i would prepare the tea and my wife would make the omelet me and wife are the two workers in the kitchen so does that mean we can just specify to have hundreds of workers to handle tasks simultaneously no how many workers can you fit in your kitchen not many why because size matters you can only fit as many workers as the size of the kitchen similarly you can only set up so many workers till the server resources get exhausted the more the number of workers the more will be your server resource utilization generally the recommended number of workers is twice the number of cpu cores plus one so in the case of a server with six cpu cores it's 13 workers this number may look small but this can manage hundreds and thousands of request per second so this is essentially how wsgi server works multiple workers handling request and each request being executed sequentially now let's move on to asgi same example of making dn omelette let's start by making the tea i'll get milk from the fridge and then the tea powder and sugar from the cupboard then i'll warm the milk but this is going to take some time stay around five minutes before the milk is warm i don't want to add the powder and sugar so should i just wait till it is warm i can actually start making the omelette and most probably even finish making the omelet by the time the milk gets warm so i go ahead and do just that i'll get egg from the fridge i'll get frying pan oil and spatula from cupboard a lighter stove i'll pour oil to the pan pour egg to pan and then pick omelette using spatula and put it in the plate once the omelet is done and also by this time the milk will also be warm so i come back to making tea and finish the work so add tea powder to milk add sugar to milk and finally for the tea in cup so both my work is completed this is the process followed by asgi the application gets the first request on saying that this request is going to take time it goes ahead and handles the next request this is known as concurrency dealing with multiple work at the same time a case where a request may take time is to bring a query to the database that returns a large amount of data that's going to take a lot of time so looking at this you may believe that asgi is going to be much faster than the blue sgi and it is sort of true asgi is better but again context matters if we look at the number of requests handled per unit of time say per second or per minute asgi can definitely handle lot more request than wsgi however if we look at individual request handling time there may not be much of a difference and also a lot depends on how the programmer writes the asynchronous code worst case scenario the asynchronous code may well take more time to handle a request then the synchronous code asgi may also be able to handle input output operations better than wsgi but when we look at cpu bound operations the difference may not be very high additionally you may be able to spot the difference only during very high load the advantage of concurrency may not be visible at lesser load taking all these into consideration we can definitely agree that asgi is the spiritual successor to wsji as it has got the added benefit of concurrency that's why popular and stable frameworks like django are moving towards asgi and why newer frameworks like fast api uses sgi by default that's all for today folks i tried to simplify this as much as possible and if you liked it please do like share and subscribe thank you

Channel: Jerin Jose

Views: 4,042

Keywords:

Id: LtpJup6vcS4

Length: 6min 47sec (407 seconds)

Published: Sat May 22 2021