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
In this video, we’ll learn a bit about what websockets are, and how they differ from the traditional way we interacted with websites. We’ll also learn a bit about how Django has tried to handle this in the past, and how Channels solves this for the future.
You can read the Channels documentation. If you'd like a Git repository for the project, here you go!
[MUSIC]
0:00
Hi everyone, I'm Kenneth,
your friendly treehouse Django teacher.
0:04
Today, I want to talk
to you about a new and
0:08
potentially life-changing feature
that's coming to Django named channels.
0:09
As you're already aware, Django
provides an incredible framework for
0:13
building Python web applications.
0:16
It has, however,
0:18
long been limited in the kinds of web
applications it can support natively.
0:19
Specifically Django has always had trouble
supporting more realtime web applications.
0:23
Powered by WebSockets.
0:27
Those kinds of applications have
just never been a great fit.
0:28
Until now that is.
0:31
The channel's package provides
native WebSocket support Django, and
0:32
his developers make real time WebSockets
applications, using the tools and
0:36
ideas there are to use to from Django.
0:39
To understand what channels is doing and
why it's such a revolutionary change for
0:42
Django we need to understand a bit
more about the technology underneath.
0:45
When you visit a website
like teamtreehouse.com our
0:49
computer is being asked by your browser
to open a connection to the server
0:52
hosting teamtreehouse.com and
then ask for some data.
0:55
The server hosting teamtreehouse.com
prepares the data like,
0:59
say the web page for this course and
sends it back to your computer.
1:02
Your computer receives the data and
1:05
closes the connection to the server
that's hosting teamtreehouse.com.
1:07
I'm glossing over a lot of the specifics
because they are required to understand
1:10
web sockets and Django channels, but a
handy abstraction, if you're old enough to
1:14
be doing this is calling an airline on
the telephone for a flight status update.
1:17
You dial the airline.
1:21
They pick up.
1:22
You request to find information.
1:23
They respond with that information and
end the call.
1:24
This one request one response cycle
is how websites have operated for
1:27
most of the life of the Internet.
1:30
And the sub Django operates by default.
1:32
The views you write,
whether they be function based views or
1:35
class based views, take in a request
object and return a response object.
1:37
If you've progressed to the point
where you're writing Django middleware
1:41
you might have an even deeper
visualization of this in your head
1:44
as you'll know that requests
move down the middleware stack.
1:46
And responses move up it until they
return to the client requesting the data.
1:49
Django middleware until very recently,
specified process request and
1:52
process response functions
that made this explicit.
1:56
Given how tightly coupled Django
is to the request response cycle,
1:59
channels is even more exciting because web
sockets change the underlying structure
2:02
of the request response model.
2:06
Going back to your telephone analogy if
the traditional request response model is
2:08
calling up the airline requesting
information, getting information back and
2:12
then ending the call WebSockets
is calling up the airline, and
2:15
then leaving the line open forever.
2:18
You can ask the airline for information,
which they'll give you, but they can also
2:21
let you know when things change, without
you asking about those changes each time.
2:23
This is the underlying
power of WebSockets.
2:27
The client, in our case the browser,
opens a connection to the server, and
2:30
leaves it open.
2:33
The client can pass
information to the server.
2:34
Or request information like always,
2:36
but the server can also send information
to the client without prompting.
2:38
If you've developed web applications
where the data updates regularly,
2:42
you can see what a big idea this is.
2:45
The client can now potentially
only load the site once.
2:47
And only load the site's assets.
2:50
The JavaScript, CSS, images, etc., once.
2:51
Once the website connection is opened
the server can update the client whenever
2:55
the information changes.
2:58
This ability to keep connections open
responding to events and sending messages
3:00
to the connected clients, isn't possible
out of the box with vanilla Django.
3:03
Channels works with Django
in a very Django way and
3:07
requires fairly minimal code changes for
all of the functionality that it's adding.
3:10
Using the channels package and the related
tools, Django gains the ability to be
3:14
event driven rather than bound
to their request response cycle.
3:17
And as a result can now handle
the always connected nature of websites.
3:20
We'll talk more about what channels is
going to do for us in the next video,
3:24
where I'll show you the dashboard
are we building with channels.
3:27
You need to sign up for Treehouse in order to download course files.
Sign up