Your very own real time chat with Django Channels

Speaker 1: Hey everyone, I'm very happy to speak at DjangoCon Europe 2021. My name is Amanda and I'm gonna be speaking about Django channels today. My talk's name is called your very own real-time chat Django Channels. I'm Amanda, as as I've said, I'm a full-stack developer at Fintas Software, a software studio uh located in Recife, Brazil. Uh I'm 23, I'm Brazilian, but I'm living in Portugal, and I have three and a half years of experience. with Django Plus React. This talk is basically like I wanted to learn more about Django channels and uh do some amateur projects with it. So uh I Had some fun with it and wanted to share the knowledge I got up to now.

Speaker 1: Please feel free to reach out to my social networks link below and let's get to the talk All right, so uh what is a WebSocket? Uh a WebSocket is a communications protocol distinct from HTTP that allows for bidirectional communication. So instead of following the HTTP logic of requests and responses and the client having to book the server in order to get information WebSockets work by opening up a connection and that's called a handshake, keeping that connection open and persistent, allowing both sides to communicate bidirectionally, and then stopping once one side, either one, closes that connection So here's a cool diagram I borrowed from AltSystems. You can find it at the bit.

Speaker 1: ly above. So it illustrates the differences between HTTP requests versus WebSockets. So as I've said with HTTP you have requests and responses and with WebSockets you get a handshake and acknowledgement and bidirectional messages until that connection ends So what is Django Channels and what is it for? According to the docs themselves, Channels is a project that takes Django and extends its abilities beyond HTTP. to me to handle WebSockets, chat protocols, IoT protocols, and more. Uh but what does that mean? So it's a library that uses using WebSockets in Django by wrapping its native async fields support in a way that is very similar to HTTP while still maintaining support for it if you want to mix it up with your long-running connection views.

Speaker 1: It powers up Django in order to allow us to build cool things such as the real-time chat example I'm going to show you in a few moments. And it's a great tool if you need to show data in real time in general. For instance, if you needed to show like uh which users were online at the moment and wanted it to be updated instantly you could totally use use channels for that purpose. You could also set up an amateur radio station using the library. In fact that's my next pack project with Changle Channels. So yeah, the possibilities are endless, but for today we're going with the default real-time chat example as it's quite simple to understand and has been covered by many online tutorials as the Getting Started project. Channels is built on top of ASGI.

Speaker 1: ASGI stands for a synchronous server gateway interface, while WSGIW stands for web. Both are interfaces that allow us to connect our Python web framework to several web servers, such as NGINKS or APESH, for instance. Django 3. 0 released back in 2019 brought support for ASGI and intends some supporting both for the foreseeable future. But ASGI is considered to be kind of like a spiritual successor to WSGI as it provides support both for asynchronous and synchronous apps, while WSGI only supports synchronous. You can find out more about that in the following link. But the most relevant fact for today is that ASGI works with applications that

Speaker 1: are built with scopes and events. So applications divide connections into two items, scopes and events. The scope can be compared to a series of details about an incoming connection. For instance, in HTTP, a scope is tied to a request. So if that request ends, the scope also ends. For WebSockets, connections work a little differently. They last for the lifetime of the WebSocket. So if that connection closes, the scope follows. That's where events come in. Events happen in series inside scope. So for HTTP, the events would be requests and responses, while for a real-time chat, for instance, we could consider the messages exchanged in the chatroom as events inside that scope.

Speaker 1: Django channels docs themselves offer two pretty good examples of the differences of scope and events for each GTP and a chatbot protocol. So yeah, let's dive into them Okay, so uh the first one is an example with HTTP. Uh it starts by uh the user making an HTTP request We open up a new HTTP TypeScope with the tails of the request path, method headers, etc. We send a HTTP request event with the HTTP body content. The channels or SGI application processes this and generates a HTTP response event to send back to the browser and close the connection. And finally, the HTTP request slash response is completed and the scope is destroyed.

Speaker 1: As for a chatbot, for instance, the user sends a first message to the chatbot. This opens a scope containing the user's username, chosen name, and user ID. The application is given a chat receipt message event with the event text. It does not have to respond, but could send one two more or more other chat messages back as chats and message events if it wanted to The user sends more messages to the chatbot and more chat received message events are generated. And after a timeout or when the application process is restarted , the scope is closed. So I hope that clears up how scopes and events work for HTTP and other protocols First, I'd like to talk about consumers.

Speaker 1: They're kind of like the channels equivalent of Django views and hold the same lifetime as a scope. The difference from views is that they're usually long running. So when a socket comes in, Django Channels will look into the routes we have set up and we'll talk about routing in a bit and we'll try to find the matching consumer for that socket or request so we can spin up a copy of it. Consumers are not a mandatory part of the library as you can write your own ASGI apps from scratch But they can make your life easier as they provide a good abstraction for you to structure the code you want to be run whenever events happen. And they also allow you to focus on more straightforward things like if you want async or sync code without making him worry about things such as threading.

Speaker 1: Here's an example of a consumer. This one inherits from WebSocket Consumer and you can see it has a few methods which you can override their connect, receive. even disconnect and uh you also have access to other methods such as accept to accept accept a certain connection close to stop uh that connection send to send data back to the web socket and uh well you can do all kinds of conditionals conditional flows with it Here's another example, which is a chat consumer. It also inherits from a WebSocket consumer. And you can see it has a few conditional flows

Speaker 1: here. uh which we can try by ourselves later. Routing is very similar to to what Django URLs is and is a way of combining multiple consumers into a bigger app. They're nestable and are valid ASGI apps themselves. And it's recommended that you use protocol type router as the root router, as you can ask more specific ones inside this one instead. Here's an example of this Here you can see the protocols type router as a root router in our SGI file, and it's supporting both HTTP and WebSocket. As you can see, the URL patterns for a chat app is uh they're nested inside uh an out middleware

Speaker 1: stack. which is a way of supporting authentication if we want to add it later on, and a URL router, which is necessary in order to interpret our paths. Um yeah, so let's talk a little bit about cross-process communication. When we start talking about our real time chat example, it's implicit that we need to figure out a way of having everyone in the chat room receive one another's messages. Each connection is handled by an instance of the applications we just learned about in the previous slides. So for each user in the chat room, we spin up a copy of that application. The question now is how do we get them to communicate? This is what channel layers are for. Well layers are an optional part of the library, which you can turn on or off

Speaker 1: through your settings file. It is needed if you want to use groups. Each one of our apps has a channel name and is able to join groups. Groups is how we're gonna get all of these copies to communicate. For now, that's everything we need to know in order to build our app Okay, so I've created uh an app called MyChat , a project called MyChat in Django, and now we're gonna get channels installed. Uh we're gonna start by running uh, oops, sorry, pip. install channels. After that's done, we're gonna add channels to our install apps Uh

Speaker 1: then we're gonna go to our ASGI file and like for Django 3 It'll come with your project. If you're using two , it's not gonna come. So you need to add it and well there's uh specific things you need to do uh for that but we're we won't go into detail as we're using free here and uh we're gonna import uh from channels dot routing import protocol type router which is the root router we're gonna use. Cool. So now instead of having this we're gonna wrap everything in into a protocol type router. And uh it's gonna be receive a dictionary, which will be just HTTP

Speaker 1: for now. And we're gonna get our uh get ASGI application Finally, we're gonna go into our settings again and uh we're gonna add um ASGI application. And we're gonna use uh my chat, which is the name of my jingle project, uhsgi. application, which is uh the name we set here. So it should be installed now. It should be done. Let's get to the next part. Now we're gonna create our chat app. So we're gonna run Python manage Py Startup

Speaker 1: Chat Cool, so it should be here. Um now we're gonna go into our settings again we're and we're gonna add uh chat to our install apps And then we're gonna create our index view. You can find one at the docs. It's pretty simple. I've modified mine a little bit. Let's see here. We're gonna have a directory called templates. And I'm gonna create uh another directory called chat. And finally, we're gonna have uh a file

Speaker 1: index HTML. So I'm gonna paste what I've created. I've added some styling here, uh inline uh but well I don't recommend you do this. Please use external uh CSS files But basically it's gonna be like the welcoming page to our chat application. Which will show what chat room would you like to enter, an input, so the user can enter the name of the chat room and an enter button. And there's a little bit of JavaScript here which will allow enter and return to send, to submit the name of the room name.

Speaker 1: And uh when uh the user clicks the button, uh it'll take the value from the from the input and it'll paste into the URL. So we're we're gonna have chat slash uh the room name and then Uh cool. So uh let's create now a view for that. We're gonna have uh the deaf index and uh we're gonna receive a request here and uh we're gonna have the term render request and then we're gonna add our chat slash index. html uh cool that's set up and now we're gonna have

Speaker 1: uh we're gonna have to create a URLs file here So we're gonna have a Python file called URLs, just like we usually do. And we're gonna import path from Django. urls. We're gonna import our views from dot import views and uh we're gonna have some URL patterns here Which will receive a list of paths. So we're gonna have a path uh empty string views. Oops, I didn't import path. Okay Views, uh dot index

Speaker 1: uh name is gonna be index And that's it. Finally, we're gonna go into our URLs and we're gonna include the URLs which just created there so we're gonna have path and chat slash it's gonna be our namespace i think Yeah, no, it's gonna be our prefix and we're gonna have uh include chat uh who else we also have to import that too. have from DjangoConf dot Rose and part include So that should be cool for us to uh

Speaker 1: to run it. So we could run with Fireman Fire on server and I'm not oops. No, that didn't work Oops, yeah, that's it. It's gonna work now. Cool. So we got it up and running. We're not gonna migrate anything as we're not using the database for this example, but uh Well I'm going to show you guys in a bit uh how that looks. So now we're going to create another HTML file uh called uh room And I also have some code handy here. It's uh the one from the tutorial, a little bit of modifications regarding styling, but well basically the same. And what this does is

Speaker 1: the chat socket will receive a new WebSocket object. uh which is kind of like an API JavaScript for provides in order for us to interact with uh servers So uh it'll take the window location host and uh paste uh W S slash chat slash room name after that as a suffix. And um we also have like uh some functions that the object provides such as on message so it runs every time uh messages received uh and it'll uh add um the message that was just sent uh to the chat log so it'll appear uh listed in the chat room

Speaker 1: We also have an unclosed function in case the server ends the connection so it provides an error in the console called a chest chat socket closed unexpectedly What else? Yeah, we have the same kind of like code we have before for like accepting enter and returns as a send, as a submit. And we also have code regarding how the message is sent to the server. So we have the send function here, the chat socket provides. We JSON stringify our message here. So yeah, basically that's it in the

Speaker 1: in the HTML file. Now we're gonna write a view for that. So we're gonna go into our views again and we're gonna write def uh room receives a request and uh the room name oops room name And we're going to return render the request. The template we've just created, so room. html. And we're gonna pass a dictionary with a room name as real name. Oops, room name. And we're gonna create a route for that now. So we're gonna go into our chat

Speaker 1: URL. So we're gonna create a path and uh we're gonna receive a string here With the name and um slash And we're gonna call views. room and we're gonna call that room So if we run that, we're gonna have a template for it, but like it won't work yet because we haven't written our consumers. So for now, that's all for our HTTP views We're just gonna have these two and um yeah we already have everything we need front-end

Speaker 1: wise and let's get into consumers Okay, so now we're gonna start writing our consumers. We're gonna write our first consumer here. So we're gonna need to create a Python file called consumers in our chat up. And uh we're gonna import uh JSON as we're gonna decode that message we're receiving from the front end. And we're gonna import uh our WebSocket Consumer from Channels generic uh WebSocket uh WebSocket Consumer So we're gonna write a check a check consumer um which is gonna inherit from uh web socket consumer.

Speaker 1: So here it is. And for now we're just gonna override the receive method. We could override the connect or disconnect, but we're not gonna need that for now. So we're we're gonna get the JSON text here and we're gonna uh load string uh text data Which we're gonna receive as a parameter here, x theta, and um we're gonna get a message from that. So Message is text using text. Uh message

Speaker 1: Then we're gonna use the method send to dump that string. So text data is going to be g zump dump string Um and uh message it's going to be message Cool. That's a synchronous WebSocket. We're gonna write that as a synchronous later, but for now we're gonna treat it as synchronous. And now we're gonna add the routing for there. So we're gonna add another Python file here called routing. And here we're gonna import repath uh because uh the URL router

Speaker 1: has some little limitations uh we can't use path so we're gonna import from django. urals import uh read path And we're gonna import our consumer, our first consumer. So here and uh we're gonna set our WebSocket URL patterns. So we're gonna receive a list here and uh we're gonna add a repath. And uh our uh string is going to be WS because it's a convention that we use WS for WebSocket protocols, uh chat.

Speaker 1: Um and then the room name, so here's room name uh W Plus And then uh consumers, chat consumer, and then we're gonna use the method SASGI. I think we have an extra one All right. Then we're going to go to our ASGI file and we're going to include this.

Speaker 1: So we're going to Go here and uh under HTTP we're gonna add black socket now and we're gonna use uh Actually, we're going to import uh our Auth middleware stack, which will allow us to get information from the session, such as like who's a logged in user and stuff that we're going to add authentication later. So from channels. alth import alpha middleware stack so we're gonna use alph middleware and uh we're gonna use also a url router so we're gonna use use uh trump channels oops we already have one here so we're gonna just import URL router

Speaker 1: here and use it down here as well And uh put chat routing uh web socket URL patterns. We're gonna, yeah, that actually we got important cool so yeah that's basically it we're gonna migrate to so python manage pie migrate So we can use session things and we're now gonna get into layers so we can get users to actually receive the messages other people were sending to In order to use groups, we're gonna need to enable channel layers. Uh the first thing we're gonna have to do, first you need to install Docker. I already have it installed, so I'm just gonna run uh

Speaker 1: Docker run and and the port I need and uh I'm gonna use Redis. Mine is already running so I'm gonna get an error but yours should uh start pulling the image uh and then we're gonna pip install uh channels res in order to use it uh and finally we're gonna go into our settings under uh ESGI application or wherever you'd like And we're gonna uh add a setting called channels channel layers and it's gonna have the backend as Redis and it's gonna run on this port Now we can rewrite our consumers to use

Speaker 1: um groups. Let's see that Now it's time to rewrite our consumer as a group using consumer. For that, we're gonna import a function called async to sync from asgi rough uh dot sync import async to sync that's gonna be needed because channel layers are always asynchronous but we're still using asynchronous um consumers so we're gonna need that function to wrap uh our group ads around and group leaves and stuff We're now gonna override the connect method. So

Speaker 1: we're gonna assign a room a room name by using the scope. and getting the URL route and the quarks finally room name We're gonna uh build a group name based on that room's name. Um so we're gonna call it room group name. And it can be like chat. Let me use F string here. Chats like underline um uh root self dot room And then we're gonna join

Speaker 1: a group. So we're gonna use that function I told you about, async to sync, and we're gonna use self. channelayer dot group add to add a group and uh we're gonna uh call it with uh self room group name and self chain channel name Finally, we're gonna accept uh we could use uh conditional folds here, but we don't want to do anything specific, so we're just gonna accept them the connection. Uh we're also gonna override uh the disconnect function. So we're gonna have DAP disconnect

Speaker 1: And um we're gonna have also an async to sync function which is gonna receive south channel layer. Um Group discard in order for us to leave the group when we close it. And it's also gonna receive self-group name, room group name and self-channel name. Uh the receipt function is gonna change a little bit. So we're gonna uh have um the message here and uh we're gonna use async to sync uh self channel layer uh group send in order for

Speaker 1: to send the message to the room group. So group send and we're gonna use self dot room group name. And the second parameter is going to be the type. So we're going to add a dictionary here. And uh the dictionary is gonna have uh a type, which will be a chat message And uh the message is going to be message Cool. So we're gonna get rid of this because we don't need it anymore. And then we're gonna have

Speaker 1: um Another function called check message in order to receive messages from the room group. So we're gonna have self and the event As I told you, this is an event inside the scope. So we're gonna have message equals uh equals not receives uh event uh message And we're gonna send that to the web socket. So text data is gonna be json. dumps, dump string, and then uh message message awesome so we should have it now up and running

Speaker 1: it's synchronous but it works let's see how how that works So here I have two browsers open side by side so we can illustrate how that messaging will work. I'm gonna enter room one here, then room one here as well. And I'm gonna send a message. It appears on both. And I can send another message here. And it appears on both. So you can refine that and add usernames and logins and stuff, but that's the basic functionality here. Now let's rewrite that as asynchronous. Now we're gonna make this asynchronous. First we're gonna inherit from async WebSocket Consumer.

Speaker 1: Then we're gonna use async def instead of def. So async in front of each one of these. Then we're gonna get rid of async to sync as uh it was just kind of like an adapter for us. So We're gonna group at directly and use the weight for that. We're also gonna use a weight for self-accept. And we're gonna do that basically for everything. We're gonna use a weight Get rid of this. Um wait a second here as well. Get rid of this And

Speaker 1: finally here. Wait, that's it So yeah, we've made that asynchronous and it should work just like the the example we did before So that's it. Thank you very much. I hope you enjoyed this beginner-ish talk about Django channels. Please feel free to reach out in my social networks linked below. And well, see you In the QA.

Speaker 2: Hi, hi Amanda. Hi Amanda.

Speaker 3: Hello.

Speaker 2: I have a question regarding WebSockets. I'm new to this one, but I hope this question makes sense So um you you mentioned about that uh synchronous and asynchronous um communication, but that web socket remain open throughout the time. For example, if even the um there is no any initiation uh between the uh maybe the chat application let's say uh if there is no any starting point then the web socket remains open throughout the um let's say throughout the live of the uh applications or how that works can you please explain it

Speaker 1: Yeah, um I I'm not really an expert at WebSockets, but like uh it remains open uh for all the lifetime until somebody closes that connection. Either the client or the server. So yeah, I I couldn't get into much detail of how WebSockets work because I also am not an expert at that, but yeah, it works like that. It remains open.

Speaker 2: Sorry. That makes sense. So that means like either of the in, let's say the client or uh server supposed to close it. So but I think um The client closing the chat application in in case of chat application, that means he just uh close the chats um browser, that means it will close, right? So that's it.

Speaker 1: Yeah, exactly.

Speaker 2: Okay, yeah. Thank you.

Speaker 1: No problem. Hi

Speaker 4: Amanda. Uh Django Channel is a fork of Django, right?

Speaker 1: Uh it's a library, I think. I'm I don't think it's a fork.

Speaker 4: Okay. So uh when uh do you think they can converge In the same project? Do you think is it possible? Ah, and who is portare avanti one second? Who can carry on uh this project? This library is uh I I want to know if uh is um um a library with the future because uh is a a lot of time that Django channels exist But uh I don't know what is the future of uh Django Channets.

Speaker 1: Yeah, I I'm not sure if I can say that as well because uh well it's I think it's been here uh since twenty sixteen if I'm not mistaken. Uh and like Django is a known uh framework for like uh having batteries packed with it. So like We don't have a guarantee that Django channels or something similar won't be released in the future with a Django update. I think only folks at the Django project can say that. But Uh up until now I haven't heard of anything that like would work as channels does. Like channel uh uh Django actually introduced support, uh native support uh for ASGI in Django 3. 0 So maybe that's something that is coming

Speaker 1: uh soon. Uh but like channels is just a way of abstracting some uh things about WebSockets and like uh other protocols. It's kind of like a framework within a framework I would say. So like it's just a way of making it easier. I'm not sure if Django would want to do that, but yeah. Oh channels thank you. Channels is an official Django project. You're right.

Speaker 4: Okay.

Speaker 1: Thank you, Glass.

Speaker 4: Thank you.

Speaker 5: Hi.

Speaker 1: Hey

Speaker 5: Uh I I have a question in in your example you were using Redis, so as I understand the chat is not persistent. Uh uh in the database. But can it be made persistent to the database?

Speaker 1: It can. Yeah, you can access the database and use it, but uh I mean that was kind of like a beginner example and like when you're using the database with asynchronous things, you need to worry uh about uh concurrency and Things such as these. I personally haven't had experience, like direct experience with it, but it can definitely be done.

Speaker 5: Okay, thanks.

Speaker 1: Thank you.

Speaker 6: Hello, can we do direct messaging with Django channels? Direct messaging? Person to person. Can you please tell the procedure of how we can do that?

Speaker 1: Uh well I think there must be some tutorials out there about it. I haven't actually done that.

Speaker 6: Okay, no problem. Thank you.

Speaker 1: Thank you I can try to find one and I'll send you later if I do. But it can be used for any kind of instant uh things Let me see if I can find one

Speaker 6: Can Django channels can be used in industry-based products? Industry-based products Like uh I wanna build a chat application and I will deploy it in the production and it may be an industry-based solution. Can we use Django channels uh for this

Speaker 1: Hm I I personally haven't had any experience with uh distributed systems in general, so I I really don't know, sorry But maybe you can maybe if someone here knows more about that.

Speaker 7: Amanda, do you have uh this project in a GitHub repository that we can do?

Speaker 1: I'll be upload Sorry. I'll be uploading that later and I'll send it in the Slack channel. I already have one, but it's like the first one I did, so I didn't want to like share the old one because maybe I I've done some modifications So I'll do I'll I'll push uh the new one and s and send it in the general chat later.

Speaker 7: Thanks.

Speaker 8: I have a question to the client side. As far as I know, um if the connection gets lost or so, you need some special handing in the JavaScript client side. And I heard there are several wrappers to WebSocket, so it's easier to do the JavaScript thing. Which do you rec recommend here?

Speaker 1: Uh yeah, you can like raise exceptions as well in the back end. I haven't shown that in my um in my talk, but let me try to find it. I think there's a section on error handling.

Speaker 8: Mm-hmm, okay. So I was looking I I heard that there are libraries and I just don't know uh remember the name so it's easier for the WebSocket handling.

Speaker 1: Oh Mm-hmm. Oh got it. Okay. Yeah, we like in the example, uh we actually use um uh error handling in javascript like the error can comes from the back end but like we print a console log there. I th of course there must be like a better way of doing this. But yeah.

Speaker 8: Okay, thank you.

Speaker 1: Thank you. Folks, I'll be going in case you guys don't have any more questions.

Speaker 4: Thank you.

Speaker 1: Thank you very much for attending. Have a nice day.

Speaker 3: Thank you everybody.

Speaker 1: Bye bye.