 Okay, thank you everyone. So let me introduce you to Remy who is going to tell us more about the new things in Django. Thank you. Hello, everyone. Today I'm going to talk about what's new in Django and especially about ASGI. But before that, let me introduce myself. My name is Remy Hupscher. I'm a native on Twitter. I've been coding with Python since 2005. I work for PeopleDoc, a company in France that is doing HR, sorry, document management. Then I worked for four years at Mozilla. And the last past year I worked with Chef Club and Monday I'm starting with Alma. And Alma is a company that is doing installment payments for online shopping applications. So what is Django? I'm sure you heard about Django. It's a framework that was created in 2003 for a newspaper in Chicago. And it got really famous because once you add your model, like your data model layer developed, you will have for free a free Django administration that is configurable. So maybe you remember this. So it's really convenient because with a few lines of code you can get started and show progress to your client. And a few years ago, Andrew Godwin started to think about I think Django. So maybe you know Andrew because he was really famous before this for adding migrations inside Django. So he builds house and then he said, oh, let's put this inside Django directly. And then a bit later he said, oh, you know, it's very a pain to handle web sockets with Django. So how can we improve that? At the time, we were in a space where Python 2 needs to be maintained as well. So it was a bit more trickier than today. But since Python 2 has been deprecated, we can now benefit from AsyncIO features. So the specification evolved a little bit. And when I say it's really new, it's like this week they shipped, so January 28th, they are still working on this, on AsyncView inside Django and making it in a way that it doesn't break existing applications. And when I filed this talk, I saw Django 3 with Async feature and I was like, oh, it's happening, I will talk about this. But it's here, but not yet, everything is not yet in Django Core. And the layer that is missing is called Django Channels. It started in 2015. And Andrew said, OK, I'm going to, I'm going to tackle this subject because it's really important. And so all this led to ASGI, the ASGI protocol I'm going to talk about. The Daphne server, which is an implementation in Python and the RedisChannel Q implementation that I will talk about a bit later. So all this is really new. The DEP009 is from 2019. So Django 3 is the first version of Django that supports ASGI directly inside Django. And so we will see. But everything starts with CGI. So I'm sure some of you know about that. For the one who don't know, it's really good as well not to know about that. And CGI was the idea that you would have an HTTP server that will handle the request and then somehow pass the request to CLI2 to handle the process of the response. So the goal was to make application with C, like web application with C. It's something that was really big. Like the National Center for Supercomputing Application is like a U.S. government thing. So they did the first specification in 1973. And the RFC arrived in 2004. So it's like not that we are still doing CGI today, which could be crazy, but... And so in the Python community, we settled on WISGI. So you might ask, why do we need to settle on anything? Actually, the goal was to make all the frameworks, the HTTP framework, some more or less compatible with between them. So we could have tooling that we could use with multiple frameworks. For instance, maybe you know about Unicorn. It's really famous to start a WISGI Python application. And you can use it with Django or with Flask because it's standardization. So the goal of WISGI was to say, you have this request and I will pass you the information in the environ. And then you will have this start response thing that will be the beginning of the response and you can write your contents after. So here we see the headers and the HTTP status code. So this worked for a long time. Like the first step about that is from 2003 and it was updated in 2010 with Python 3. So what's really important is that there is just this function, application, and that's it. So after you do whatever you want inside and each framework will implement its own way. So what is important here is that also WISGI, each framework doesn't have to pass the HTTP request and all this is part of WISGI. And then the HTTP, like the web framework, only has to handle writing the response. And then a few years ago, we started talking about ASGI. So when I prepared these slides, I was like, oh, let's see what Wikipedia says about ASGI and actually nothing because there is no even ASGI page yet. It's a spiritual successor of WISGI. It means that if you have a WISGI application and you want to add ASGI support, you can because you can just use ASGI and say, oh, by the way, this is my WISGI app. But it will provide more information and to handle async Python code. So the main difference with WISGI is that the application is now a coroutine, an async Python function. So it comes from async.io. It takes a scope that we leave for the connection of the user. Before, we were talking about request and response and now we are talking about connection and events that happen within this connection. So this example is WebSocket. For instance, we can receive something and then send something else. But it also works with HTTP. We can receive the request and send the response. So a lot of people might say, why do we need another standard? We already have 15 competing standards. Let's create another one. So it's not totally true for this case because WISGI is really close to the request-response model. And we want something like... This is a request-response model that we know from HTTP.1. You get a request from the client. You get back a response. And if the response takes time, you might have a timeout. But before that, like if it takes 10 seconds, for instance, all the other clients have to wait a bit like when you are at a shop and there are a lot of people in front of you. So with Python, you can't handle multiple clients at the same time with the same process, at least with WISGI. And so what we ended up doing was spawning multiple workers with micro WISGI or Unicorn to handle multiple requests at the same time. Also, if you try to work with WebSocket and Python with WISGI, it's like, okay, so I have my WISGI server and then I need to start another server for the WebSocket. Or I don't use WISGI. So WebSocket is different because you've got one connection that stays for the duration of the session. And then you will have events. So it doesn't fit in the WISGI request response model. And we can't really afford to have a worker per client. Like we could say, let's spawn 20,000 processes. So it looks a bit like that. You can have multiple messages, response. You can have responses while reading new messages. And then you might have heard about HTTP2 or even HTTP3. And it's a bit the same thing. So we have one unique connection opened by the user. And then the client can ask multiple files and we can answer them like mixed. You can have chunks that are mixed. And the server can also push you files that you didn't ask for. For instance, it says, like, oh, you loaded this stylesheet, but I'm sure you will need these fonts. So it doesn't fit with the request response model either. So it's really similar to WebSockets, actually. HTTP3, so it was previously called Quick. The main difference with HTTP2 is that it uses UDP instead of TCP because now we are using the web behind TLS. So we already have some guarantees that TCP provides. And if you want to know more information about this, I encourage you to watch Daniel Steinberg talk in Johnson Theater at 4. The only issue with that is that there is an awesome talk happening here at the same time about HTTPX. So what to say about that? So with G-server, it works. Like, if you are in the request response model, it works. If you are not in the request response model, it doesn't work. So either you use Node.js or you find something else. By the way, we were really afraid about Node.js at the time because we didn't add a NIO loop for Python. Thanks to Python 3, this is fixed. And the ASGI promise is that you will have a connection from the server. It will create a ASGI application and call the connect method. Then you will have the request from the receive function. Then you can send the response. And eventually, when the connection closes, you will handle the disconnect method. And you can have multiple receive send in any order. Like, it's not limited to only one. So instead of describing requests and responses, we will describe events. Events that will have a type. The ASGI server will keep the connection and the scope for each connection. And then everything that arrives from the client will be sent through receive. And everything that goes from the ASGI application to the client will go through the send function. And the HTTP request is just another kind of event. And then Django channels add something more on top of this because sometimes if you are doing a chat application, for instance, you can't be limited in one client. You want to be able to exchange messages between your applications. So an ASGI application can also register to a group, send message to that group. So every people on the same page, for instance, can share messages through their web sockets. And the benefit of that is that you can also use Channel Q to handle other kinds of messages. I don't know if some of you are familiar with Celery, our background tasks. Sometimes you want to create a thumbnail of the picture or user send you, but you don't want to do that during the request response handling. So you can delegate this to a worker through the channel as well. Telling him that, oh, by the way, when you have some time, give me this thumbnail. Yeah, so that's basically what I just said. The other benefit of this is that you don't need to write asynchronous code to handle your request response thing because it's an event that can happen in a worker. So this is really good because it means we don't have to change anything in the existing application to use ASGI. And that's what also the tweet about the PR was about that, like, how do we handle on the same code base as sync functions and synchronous functions? So this is all taking care of for you. ASGI is already popular, especially with Starlet and Fast API. I'm pretty sure if you had to do some APIs in Python last year, you would have noticed this framework. Django 3 shipped ASGI endpoints. So the next version will have more tooling. And yeah, if you want to have all that I presented to you today, you can have a look at Django Channel. There is a tutorial. You can do it in one hour. And you know everything you need to know. As a conclusion, I would really... Like, you should really have a look at ASGI. You should try Starlet, I guess, and learn about async.io if you didn't because it's really amazing. Thank you for your attention. I am open to questions and I also have a quick demo. So feel free to ask questions. Yeah, OK. What's that? It's sublime, right? Can you show me the code? Yeah, from... Yes, thanks. So... Oh, we can't see anything, actually. OK. Perfect. No, but we can have questions. The room is about to give a demo. So if you want to stay a bit longer, it's fine. If the people leaving the room could be pretty quiet, so the people who are still interested in the rest of the talk could follow, thank you very much. And please don't step behind on the stage. You do the all turn. Thank you. So, there is a question up there, maybe? OK, so how does it work concretely? With Django channels, you can define your application, your ASGI application, like that. Automatically, it will take your views, like your URLs, and handle them for you. And then you can add other kind of workers. So for instance, WebSocket, you can say, I want to validate it with the origin, like a load host I have. I want to handle authentication automatically. And then I'm going to use WebSocket URL patterns to handle them. And here's the channel thing. It's to be able to handle the background tasks. So here I have a thumbnail generate consumer that I can send message to. So I have the chat application with WebSocket. And I can give it a room name. So I can handle messages for different rooms. And then the consumer looks really similar. So we can see the connect. So when someone connects to the WebSocket, I register them to the channel group with a group name. When they leave, I remove them for the channel group. When there is a new message, I look if there is an image in this message and I forward it to the thumbnail generate worker. And then I publish the message to the group. And each time there is a chat message in my group, I send it to the WebSocket. And the type of the message here will be the name of the function that handles it. So for my thumbnail, for instance, I have just a consumer because I don't have URLs for it. And I ask to generate a thumbnail and that's it. So here it's just working the URL. So that's pretty simple. The URL here is just the normal chat HTML URLs. And that's it. In my settings, I just said that I want to use the channel application rather than the default Django one. So if you have questions, I will be glad to talk to you. You can also send me messages through Twitter. Have fun!