Congratulations! Our dashboard is up and running and responding to data changes. But it’s not much use running just on your machine, so how do we get Channels deployed?
Our dashboard is ready to be shared with the world. 0:00 But how do we deploy channels? 0:02 To understand that, 0:04 we need to learn a bit more about the tool ecosystem that's around channels. 0:05 Traditionally Django has accepted web requests over protocol called W-S-G-I, 0:08 the Web Server Gateway Interface, or WSGI. 0:13 WSGI is like Django, 0:16 well adapted to the traditional request response model of the classic web. 0:17 To serve more event driven requests, like web sockets, something new is needed. 0:22 ASGI, the asynchronous server gateway interface, 0:26 was developed by Andrew Godwin alongside channels to solve this problem. 0:29 Additionally he developed Daphne as an implementation of the protocol and 0:34 Daphne is how the channels apps get run. 0:37 It's highly recommended that you read the deploying docs for the channel's project. 0:40 Every web application is slightly different, so I'm not going to try and 0:44 tell you exactly how you should deploy Django with channels. 0:47 Instead let's go over some considerations and 0:50 gotchas that you should keep in mind when you deploy. 0:52 The first thing to think about is our choice of channels layer back end. 0:54 We're currently running channels with the in memory backend but that won't work for 0:58 deploying it in any sort of scale even aside from just the larger number of 1:01 requests and clients, in a production environment you might be using many more 1:05 processes over multiple machines so there wouldn't be a shared memory to rely on. 1:08 The recommended channel layer for 1:13 a deployed application is the Redis back layer. 1:15 Luckily the configuration for the Redis back end requires only a few 1:17 changes to your settings dot pie and no changes to your channel's code. 1:20 The other nice thing about using the Redis back end is that you now have reddest as 1:24 part of your application technology stack. 1:27 Once Redis is available, you can use Redis back to Django caching and 1:29 have a short term data store for your application, 1:32 allowing you even more flexibility in the kinds of applications you create. 1:34 The next consideration and 1:38 potential gotcha is the web server you use to run your channel's application. 1:39 If you're using a platform as a service like Heroku, they probably have docs for 1:43 how to get started deploying channels. 1:46 If you're running your own server or using a platform like Amazon Web Services or 1:48 DigitalOcean, you have more decisions to make. 1:51 Channels communicates with the web, over a protocol named ASGI. 1:54 And right now there's only one official web server that speaks ASGI, 1:58 the Daphne server that ships the channels. 2:01 On a platform as a service you can have Daphne be the command that the platform 2:04 runs, and let the platform worry about any sort of proxying. 2:07 If you're running your own server the current recommendation is to let 2:11 Daphne handle all web traffic which is fine if you're running a simple site and 2:14 dashboard like the one we built. 2:18 The thought is you would manage Daphne processes with a process control tool like 2:19 Supervisord, and not have a traditional web server in front of it. 2:23 Daphne can also be run behind a proxy like NGINX, but 2:26 that documentation is a little more thin on the ground. 2:29 If you're planning on using channels to serve production level traffic, 2:31 which by all accounts it can definitely support, 2:34 you'll probably want to pop into the Django channels IRC 2:36 channel on Freenode and see what the current best practices are there. 2:39 Whether you're running channels on your own machine or 2:43 platform, the biggest gotcha is how channels scales. 2:45 With traditional web applications you would horizontally scale the application 2:48 by spinning up more and more web processes. 2:52 Processes that serve the whole app and 2:53 could handle a complete request response cycle. 2:55 With channels you'll have at least one web process, but 2:58 you'll have many more worker processes. 3:01 The web process is something of an organizer, 3:03 sending tasks to the worker processes. 3:05 The biggest gotcha here is making sure you have plenty of worker processes. 3:07 That's why running Python manage.py runserver spends up four workers. 3:11 Not having enough workers can result in a frustrating situation where your app 3:15 doesn't respond to requests and you can't figure out why. 3:18 I hope this workshop has given you a taste of what channels can do. 3:22 And in many ways I've only just scratched the surface. 3:24 Channels adds asynchronous capabilities to Django in a way that's 3:27 never been possible before, and a whole new realm of projects is open to us. 3:30 Happy building and thanks for watching. 3:34
You need to sign up for Treehouse in order to download course files.Sign up