Heads up! To view this whole video, sign in with your Courses Plus account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
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?
You can read the Channels documentation. If you'd like a Git repository for the project, here you go!
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