 So we have Viku Agarwal right now who will be talking about Python web community, what's going on, and all about it. Go ahead. Right. Iran, what is going on, and especially in Python web? Now people trying out web development in Python, whether they've had experience in some other language or they're trying out for the first time ever, they do find quite a lot of things to get started with and do it very easily. So the thing is that sometimes, if a lot of tools get added when you add it up into a text tag, things get a little bit overwhelming, and it gets a little hard to keep track of all of this stuff and what stuff does what. Today we're going to just look around all of those moving parts, try to understand all of them as a whole and how all of them together bring out a fantastic web ecosystem. So about me, my name is Vibhu. I've been using Python for the last four and a half years and have been involved in loads of web related projects. So yeah, I've played around a little bit. OK, let's start with basic HTTP. So client, there's a client, there's a server. Client sends in the HTTP request. Server responds with an HTTP response, pretty much that. Talking about static websites, client must specify a particular HTML file from which they want the content from or some other file. What the server would do is to take the content of that HTML file and embed the content of that file into the HTTP response and return the response back. So that's static website. But how about if you want to store some result into a database or you want to run a complex query or call it third party service, you can't do that with static websites. You can't do that with dynamic websites. What happens in dynamic websites is that you'll have a dedicated backend server, and the backend server would load a script. We usually call it as an external script, which has a few lines of code. It processes on those HTTP request inputs and then return the response back. That way, you've got your thing running. And these days, you can write your external script in pretty much any language. So that's a good thing to have. So how about we have a dynamic website wherein you want to serve both starting and dynamic content? Well, you can do this by using nginx. What nginx does is that it redirects the request. Whenever a request comes for the static content, it redirects to the static files. And whenever a request comes for the dynamic content, it redirects to the backend server, which we usually call it as an application server. So note is the first task over here for our application server, that is to just listen to the requests. And for that, how about we reserve one process just for listening to that request? So we'll just denote this particular circle over here, which we'll just listen to the requests. Now, once we have a request, we need to understand what do they want. For that, we need to parse them, understand them, break them down into tokens so that we can take the actions on those tokens and give some result. Now talk about that this application server loads this external script. This loading happens through forking. Let's go through this once again. There's this main server, main process, which just listens to the requests. So our request arrives. This main process listens to the request and then spins up a new process, or forks a new process, which in turn loads the external script from the hard disk, bring it into the memory, and then the script runs, and then returns the response back. Well, all of this is discussed very in detail in this RFC, that is the CGI Common Gateway Interface, in which they discuss how to load, invoke, and execute the external script. Well, they also discuss how to process the HTTP request input parameters. That is done using environment variables. So whenever request arrives, the main process listens to the request, parses that request, breaks it down into tokens, and then feeds all of the HTTP request inputs into the environment. And when the environment is filled, this main process forks a new process, which loads the external script. And then the, because this is a child process of that parent process, this child would have the environment variables of the parent process. And then what the script would do, is to just pick up those environment variables, which in turn are HTTP request inputs, and then works on it, processes it, and returns the response back. So that's our CGI. So everything good? Not quite. Because these fork and this loading of external script from the hard disk are heavy tasks, because these are system calls. And these are the few things which you may want to avoid, because these are not corresponding to a particular request. What you want to, what you can do, is to adopt a pre-foc model. What we do in a pre-foc model, is that we spin up some number of processes in advance, which load the external script from the hard disk into the memory in advance. So whenever a request arrives, this application server listens to it, and then takes one of the available pool of processes, and then assigns that request to that process, and then the script runs, and then it is on the response back. And so over here, there was no overhead of forking, because that had been done in advance, and there is no overhead of this loading the external script from the hard disk, because again, that has been done in advance. All right, since we introduced a lot of processes into our mix, we also want that our application server should be able to handle increasing or decreasing of processes on the fly, because we want to reuse or utilize the resources efficiently. For that, we need that our application server should have this process management feature. So that is one other thing which gets added up onto the application server. So we talked about this external script. What can the external script do? Well, it can do anything, but what are the common tasks of this external script? One of the common tasks of the external script would be to generate dynamic content. Well, you can do that by embedding dynamic content into your HTML, which you can do it by strings, by formatting the strings, or you can use templates. One other common task, which is done in the external script or backend is to route. They can be multiple HTTP paths, and you want to route, you want to map particular path to a particular function, which are also known as URL dispatchers. And this whole thing of mapping of particular paths to the respective URL dispatcher or function is known as routing. And there are a lot of other common tasks which are needed in the backend servers, which you might not have seen people or web developers writing in their everyday application, because all of these are separated out in a separate tool in what we know as web frameworks. Now, Python web community might be familiar with these web frameworks in the form of Flask or Fast API or Django. Now, a lot of talk has been already done yesterday as well about the different web frameworks. Let's just quickly take a quick look at the Flask code. So import Flask, you instantiate Flask, and then you define your path along with your function or your URL dispatcher. So what's happening over here? What's happening is that your web framework or your Flask in this case forms a layer around your business logic. So whenever a request arrives, the web framework handles it first and then it executes some code and then had to hand it off to your business logic. Your business logic then runs and then it hands the result back to the web framework. Web framework may perform some exit operations based on the input and then it returns a response back. So that's how web frameworks adds up onto the functionalities into your code base and allows you to focus on your business logic rather than the unnecessary or necessary simple tasks which are needed in everyday applications. Moving on, Django is a very mature and one of my favorite web frameworks and highly maintained and it provides a lot of features. If people who use Django might be aware that the Django provides a lot of features using middlewares. For people who have not used middlewares, what Django middlewares do is to add up extra layers between your web framework and your business logic. So what happens is that whenever requests arise, web framework handles it first, executes some code, then it hands off the result to the first middleware layer. The first middleware handles it, then it hands it to the second middleware layer, till it reaches your business logic and reverse way back. That's how the Django middlewares add up a lot of features into your system or code base. Back to our application server. A lot of people might, or I think web community might be familiar with application servers in the form of GU and Econ or Uwiski. Now, before we dive deep, let's just quickly take a look at WSGI or what people call it, Wiski, because this Wiski term comes up a lot, comes up a lot in our documentation, deployment, everywhere. So let's just take a look at that. Remember CGI, which is said, which was a specification which said how to load, invoke, and execute the external script? Well, WSGI, Wiski went even further in saying that how this server and external script would behave, how to prototype all of them. So let's just quickly, just let's just take a look at that. So what Wiski says is that we'll have two parts. One would be the application server, one would be our external script. These would be, should be made kind of independent of each other. And if they are made independent of each other, they can be developed independently that will push towards rapid development, faster development. So how can they be made independent of each other? If one part knows about the other part, then probably the things will go again. If one part knows about the other part, knows about the other part, how they are trying to, how they will behave and what they're expecting, what is expecting of, what is expected of them. So all of this stuff is declared a prototype these can be made independent of each other. So Wiski helps us with that. It declares that our external script should be prototyped into a simple function and what we usually call as an Wiski application. So this application should take two parameters. The first one, what it would receive would be a dictionary or a hash map of environment variables. The second input which it would receive would be a function. And this function has to be called somewhere inside the application which in turn is expecting the HTTP responses status and headers which you're finally intending to pass back and then you'll finally return the response body if you have any. And in between all of these, you're going to write your business logic. So where, how does web framework fit over here? What web frameworks do? Okay, let's just quickly take a look at the code. So remember the Flask code? This is this app word over here. This is the Wiski application. And if you go to your Django project and try to locate WSGI or Wiski.py file, you'll find this last line application. This again is a Wiski application. So what web frameworks are doing is they are wrapping all of your business logic, all of the stuff you write along with their features and then they just plug it over here. So now notice that app forms the layer around your web framework and your business logic. Something like this. So the question arrives, app handles it, hands it off to the web framework and then through the middle layers, if any, to reach your business logic and reverse your back. So that's how the app forms a layer. All right, so that was the right side or external script side of our WSGI. How about the left side? Again, these are application servers or which are known in the form of G and Econium, U, Wiski. Now, the good thing, good news is that we've already discussed the features of G and Econium, U, Wiski. These are the features which we already discussed like parsing the request, listening to the requests, handling the process management, all of that is all that sort of stuff. So this is the usage of U, G and Econium, U, Wiski. Moving on, G and Econium reduces two new terms. One is the master process and one is the worker process. Master process is the one which just listens to the request and the worker process are the processes which actually handles the request or which loads external script into the memory and runs the request. So let's just quickly go through this once again. So your idea of business logic along with the stuff provided by your web framework, you wrap it all up into an application. This application is then passed to the web server. Web server then may take some external or other parameters as well like how many number of processes to spin up. Then it spins up that many number of processes which loads this code from the disk into the memory. It doesn't call it at this point. When a request arrives, it takes the one of the processes and then the app is called, this function is called. So that's how the web thing is set up. Yay, we're done. We know how the web works. Well, not quite. Now, asynchronous is a topic which has been already touched by Sebastian in his keynote yesterday and Korean must have discussed about this in his keen in his talk earlier today, but I'm here to give my perspective or a different perspective or a perspective from the web world. So let's just quickly discuss what asynchronous is. Asynchronous is a thing which is matured a lot in the last three or four years. And this has pushed towards the rapid development of tools and libraries in all domains, whether it be data science or web. And as such, there are a lot of tools and frameworks, relatively newer frameworks and tools out there which helps us in asynchronous web development. So what is asynchronous? Let's just quickly discuss that. Let's suppose you and your opponent or your friend are playing a card's game and you played your turn and this is now it's your friend's turn to play the turn. Your friend is a little bit slow in thinking about a turn. So what you did is you thought about an idea. How about you attend a bike or talk in the time your friend is thinking about a turn? So what you did is to utilize your time efficiently, utilize your time to the fullest. That is exactly the goal of concurrency. Utilize the resources and time to the fullest. So your opponent thought of a turn, they played the card and then they're looking for you. They were just going to poke you, but then there was a negotiator who was standing who stopped them from poking you and asked them to just list out their name and they added their name to the list of tasks you have. So once you were done the talk and hopefully happy with my talk, you went back to your negotiator and negotiator presents you with the list, which you list of tasks. You see your friend's name over there. You say, hi, I'm available. And so you and your friend then play the turn, play the game. So this list and this negotiator and this popping off the task from the list, executing it midway and then dropping it and then adding it back to the list and then cycle like this. This is something which signifies or denotes event loop. This was a little bit confusing and you can check out the other talks or you can check out this playlist as well. This is awesome. Okay, what is this ASGI, asynchronous gateway interface? This is again a specification which is added for asynchronous web development. It's just like WISGI, but it adds a lot more flexibility to WISGI. And as it says, it's a spiritual successor to WISGI and is a superset to that. So again, just like WISGI, ASGI states that there would be two parts. One would be the application server, one would be the external script. They should be made kind of independent of each other and they would be made independent of each other if external script has a prototype again. But before moving into the prototype, ASGI introduces two new terms. One is the scope, one is the event. Scope is something which contains the information about connection. If you're using HTTP, it may also contain information about HTTP request headers which in turn contains information about connection preferences as well. Events are just the fancy name of saying messages. These are messages which are exchanged between the web server and the application. Let's take a quick look at application now. Again, this should be a function, but notice that this is an async function now. This should be available. And it is expecting three parameters. First one would be the scope about which we discussed right now. The second parameter would be again a function. This would be an async function which when awaited on would give you an event or the message from the web server. Now you can take an action based on this message and then return a response back. Using the third parameter which you received, this is again a function, an async function which you can await and it in turn is expecting an event in it. Notice that event or message is in the form of a dictionary and it has got to contain this type key which contains the category of this message so that a particular action can be taken on this message. And notice that we don't have a return statement over here which is a good thing. What that means is that once you've instantiated or called your application once, you can put these three statements on a loop and you can take advantage of receiving multiple messages and sending multiple messages. This helps us in implementing web sockets. All right. Just like with G5 frameworks, we have asynchronous web frameworks as well. Why do we have asynchronous web frameworks when we already have synchronous web frameworks? This is because synchronous code is not that straightforward or that easy to be converted into an asynchronous code. A lot of things have to be kept in mind so that our code is taking full advantage of concurrency and our resources. So we have, as a result, we have our asynchronous web frameworks. Now, the functionality of the frameworks is the same. It's just the differences that these are asynchronous in nature. Sonic is a lightweight web framework which is very fast and I haven't used it personally but I've seen people using Sonic and they give good reviews. If you've been using Flask a lot and you want to dive into asynchronous development, you can check out Quartz because Quartz API is very similar to Flask and you can just quickly get on with asynchronous development if you go with Quartz. Channels is a project which you may or may not call as a web framework because it's an extension designed for a Django application, Django project, which gives it the asynchronous functionalities whereas Django is not natively asynchronous in nature. Fast API and Sonic is something which was already discussed in Sebastian Keynote yesterday and it's a web framework which Fast API is a framework which helps us in focusing or developing web APIs. Sonic is a very good web framework on which the Fast API is built on. Just like we had servers on the VisGee side, we have servers on the AsGee side as well. That is the left side over here. These are in the form of Hypercon, Daphne or Ubicon. Hypercon is created by the creator of Quartz and it supports HTTP one, two and I think three as well. Daphne is a project which comes under Django. The documentation says that it is intended to be used along with channels but I've seen people use Daphne with other web frameworks as well and it seems to have worked great. Ubicon is the project which focuses on performance and it's supposed to be one. Yeah, I suppose it should be one point one right now and it really focuses on performance so you can get the best performance out of it. So for more discussions, check out this link. So a request arrives, the server handles it, takes over one of the processes and then executes the script. That's it, it was just like VisGee. But the main difference is in the fact that these are asynchronous in nature. What that means is if multiple requests arrive with this application, the request gets scheduled serially even if some request goes for the Iobondo operation. Whereas with ASCII, if multiple requests arrive, some other request which should be scheduled in future which was scheduled in the time when some other request went for some Iobondo operation. This gives a better response time for every request for most of the requests and it also saves in the overall time, so performance boost. So if it can take full advantage of your ASCII applications you are very good to go. So conclusions, takeaways are that now you know what are the different parts of web framework, web servers. There are a lot of tools as well which I wanted to add onto the tech stack. For example, a web framework extensions and web server extensions, other worker processes, all that sort of stuff. These do add up, add up. But what I discussed today were the basic stuff and are mostly used in almost every other application. So now you know that which part does what and if you sometimes see a bug somewhere in your application you know where to look out for and then probably file a bug report over there or maybe fix it yourself. So yeah, that's a good thing to know and carry it forward in making your entire code base working. Where did I get all of this information from these wonderful, wonderful documentation of wonderful, wonderful projects and I'm up for some questions. So how much time is remaining? Although if a lot, not a lot of time. Yeah, here we go. If a lot of time. Yeah, we do have a couple of minutes. Okay, so I'll just be taking some questions. If we don't have enough time I will be there in some hallway track. Probably the web development one, preferably the web development one and still it was there of course. So yeah, just hit me up with some questions. Yeah, that's great. It's great that you informed them of it. So we do have some questions. So the first one goes kind of like this. So we have Django, Flask and Fast API. Which one would you recommend to start with? The thing about, the good thing about being in the Python community is that you've got a lot of web frameworks to get started with. But over the time, the main thing which developers say or may recommend is that your choice of a framework really comes down to the kind of work you are going to do. For example, if you're going to do some normal operation or simple web framework stuff which is provided by Django which are the features which are provided by Django. Django is one of my favorite web framework I've used Django a lot. Django works in a lot of cases. But if you want to focus on, if you have a particular need, maybe if you want to use no secret database you can use Flask and if you want to play around with or actually use asynchronous, write asynchronous code or use the concurrency you can use Fast API. And also if you want to develop web APIs Fast API is the thing to go. Certainly, certainly. I think like you mentioned, Sebastian session yesterday also kind of pointed at that. There's also a poster session which is there. You guys can go and check it out. It's about Fast API. So thanks a lot, Vibhu. It was a really nice session about the web community in Python and the various frameworks which are there in Python for folks who are interested in the web. Thank you. It was a great hosting here.