
Real-Time Django: Get Started with Django Channels - joeyespo
https://blog.heroku.com/archives/2016/3/17/in_deep_with_django_channels_the_future_of_real_time_apps_in_django
======
picozeta
The best thing about Django is its documentation. It is one of the best (if
not _the_ best) documented projects I have ever used. Example: Let's say you
are reading about Django authentication related stuff and somebody links for
further clarification to
[https://docs.djangoproject.com/en/1.7/topics/auth/default/](https://docs.djangoproject.com/en/1.7/topics/auth/default/).

Bam! You immediately know it's outdated (emphasized by the headline) and
switch to
[https://docs.djangoproject.com/en/1.9/topics/auth/default/](https://docs.djangoproject.com/en/1.9/topics/auth/default/).
This might seem minor, but I highly appreciate such attention to detail. And I
really like the official page's layout, look and feel which concentrates on
information, rather than stupid, flashy animations. Ha, looks like I'm getting
old.

~~~
uptownJimmy
Absolutely in agreement. I am 2 years into my app dev career, all of it spent
pushing .NET around in the enterprise.

But I need to expand my skill set, I need to continue working remote, and I'm
interested in OSS in general. Honestly, Python and Django seem like heaven
compared to the other language/framework ecosystems I investigated. Not gonna
name any names there...

But the documentation for Python and Django is A++. It's just really, really
good. I can't praise it enough. The whole setup is elegant, intelligent and
accessible. I really appreciate that.

~~~
wikibob
I'm in a bit of the same boat lately, deciding between updating my skills to
the treadmill of JS frameworks, or Rails 5, or Django. Have you found any good
leads on Django remote work?

~~~
uptownJimmy
I did a cursory survey, and saw that remote Django jobs existed, but I didn't
do any due diligence. I figured I'd learn the stack first. ;)

My rough impression is that Rails remote jobs are relatively thick on the
ground, but that any OSS dev stack will be better represented in remote job
postings than any enterprise stack. So since I prefer Python to Ruby, and
Django to Rails, I figured I'd take a leap of faith.

JavaScript is simply not going to be my main dish, not for the time being.
Things are just too crazy there. I don't have time to play whack-a-mole with
my career skill set.

------
bliti
This is great news. Django is a great web dev tool and having websockets
support is icing on the cake. I guess this adds more weight to the thought
I've been having: That Web applications are moving away from MVC and more into
messaging layers. Front end JS frameworks have pushed things to be this way.
Which brings the Web into a pseudo native environment of sorts. Anyhow, will
be happily tinkering with this from today onwards.

~~~
jkarneges
For building clustered backend services, messaging is great. And Django
Channels looks awesome.

However, in the context of the web (the client/server boundary), I think we
need to be careful about how messaging is used. The web is made up of
resources with URLs. HTTP is typically used for data transfer, and for good
reason.

I sometimes see webapps communicating entirely over WebSockets. I don't mean
just the realtime push part, I mean everything, request/response traffic and
all. I understand that HTTP is suboptimal in certain contexts, but let's not
throw the baby out with the bathwater.

~~~
Yaggo
> However, in the context of the web (the client/server boundary), I think we
> need to be careful about how messaging is used. The web is made up of
> resources with URLs. HTTP is typically used for data transfer, and for good
> reason.

"Careful" == do not break urls, use pushState and make sure equivalent
document is returned for GET.

~~~
jkarneges
Sounds good to me. :)

------
cdnsteve
Nice to see Django moving forward but is still backwards friendly. Love that.

"Channels is to become a built-in feature for Django 1.10, but in order to aid
adoption and to encourage community usage and support, it will also be
backported to Django 1.8 and 1.9 via a third-party app."

ASGI seems to be a very important piece of this.

"Despite the name of the proposal, ASGI does not specify or design to any
specific in-process async solution, such as asyncio, twisted, or gevent.
Instead, the receive_many function can be switched between nonblocking or
synchronous. This approach allows applications to choose what’s best for their
current runtime environment; further improvements may provide extensions where
cooperative versions of receive_many are provided."

------
leoh
I am consistently impressed with the thoughtful API abstractions django
develops. They were a little late to the game on this — you had to use other
libraries to do WebSockets for a while. But they did this right.

~~~
Walkman
maybe it is possible to be more specific and say "I am consistently impressed
with the thoughtful API abstractions Andrew Godwin develops". There are other
great Django developers of course, but he is just insanely good.

~~~
acdha
I think part of what he's insanely good at is carefully soliciting feedback
from other people, particularly those with a lot of experience with similar
but distinct problems. The final spec goes back close to a year
([https://www.aeracode.org/2015/6/17/beyond-request-
response/](https://www.aeracode.org/2015/6/17/beyond-request-response/)
[https://groups.google.com/d/topic/django-
developers/mt1mTNvc...](https://groups.google.com/d/topic/django-
developers/mt1mTNvc0Ew/discussion)) and the polish really shows.

I think of that as a “senior developer” skill which is easy to underestimate
since it doesn't directly translate into tons of commits but is so critical to
the long-term success of a project.

~~~
abledon
'the polish really shows'

Can you explain what you mean by this?

~~~
skolsuper
polish as in shine, not Polish as in Poland

------
sciurus
To get more insight into the design of channels, see (my coworker!) Andrew
Godwin's article "Laying the Channels Groundwork" at
[http://www.aeracode.org/2016/1/3/laying-channels-
groundwork/](http://www.aeracode.org/2016/1/3/laying-channels-groundwork/)

------
616c
Here is a good interview with WSGI/Django devs talking about the rationale and
starting work on the Django Channels project.

[http://pythonpodcast.com/wsgi-2.html](http://pythonpodcast.com/wsgi-2.html)

~~~
zokier
The big question is if other frameworks will adopt this ASGI/Channels model
also, or will it remain a Django-specific thing.

------
collinmanderson
It's great to see Django getting first class support for real-time. I remember
building a hacked-together real-time chat 10 years ago using Python using
ajax, but I haven't done much since. I'll have to check it out.

------
pritambarhate
It's great that Dijago Channels will allow a developer to use same framework
and ORM to build the WebSocket based applications. However I think from the
deployment and scaling plan, it's better to keep HTTP / REST servers separate
from the Web Socket servers. Both models scale differently. So keeping them on
different infrastructure would allow to scale those 2 systems independent of
each other.

~~~
danpalmer
As far as I can tell, they are. In production you'll run your WSGI servers for
the HTTP/REST side of things, your "ASGI" servers (with daphne) for the
websockets side of things, and your workers, all separately. That should mean
that each can be scaled pretty much independently.

------
travjones
This is great news. For those with flask apps, check out flask-socket[0] for
websocket support.

[0]: [https://github.com/kennethreitz/flask-
sockets](https://github.com/kennethreitz/flask-sockets)

------
spriggan3
I did some Django years ago and if I remember correctly Django wasn't a
"server" ie long running process but more like CGI. So how does it work
exactly ? is there some python code running as a demon polling socket events
and interacting with the actual Django app ?

~~~
ubernostrum
The underlying model for all Python Web apps -- WSGI -- is CGI-like. But the
actual deployment of WSGI almost always involves a long-running process or
processes, which keep the application code in memory and then expose the
appropriate WSGI API to whatever Web server you're using. Switching that from
"expose WSGI API" to "expose ASGI API" gets you Channels :)

------
cdelsolar
This sounds amazing! Very excited to give it a try. I am working on a side
project that I wanted to add real-time capabilities to and I'm not very happy
about my Go + Django hybrid solution.

------
thatgibbyguy
I'm someone who moved to django from meteor (for work) and at first I was
shocked at how similar they were, but after that I was shocked at how out-
dated django seemed.

Websockets was just one of those issues so it's good to see it addressed.
However, with meteor's DDP there's still no comparison. Looking ahead to
Reactive GraphQL that meteor is working on, django seems to be permanently one
step behind for the foreseeable future.

These are just my opinions, but overall definitely great news for django
developers.

~~~
zeemonkee3
So does meteor support SQL backends yet (not talking unsupported plugins or
whatever MDG is promising to do Real Soon Now).

If it's still tightly coupled to MongoDB then there is zero chance I can see
it being used for anything more serious than an MVP or hackathon project by a
company with non-trivial data requirements.

------
DanFeldman
Does this replace Celery+RabbitMQ/Queue service?

~~~
jaxondu
From the article:

"Remember: Channels is a general-purpose utility for running background tasks.
Thus, many features that used to require Celery or Python-RQ could be done
using Channels instead. Channels can’t replace dedicated task queues entirely:
it has some important limitations, including at-most-once delivery, that don’t
make it suitable for all use cases. Still, Channels can make common background
tasks much simpler. For example, you could easily use Channels to perform
image thumbnailing, send out emails, tweets, or SMSes, run expensive data
calculations, and more."

~~~
mrfusion
So what can't it do that celery does?

~~~
izak30
Celery does a ton of things that channels doesn't currently do. Celery has a
lot of workflow concepts built in (Chains, Chords, etc). Celery also has
prioritization, and a fairly robust ecosystem that channels may take a while
to deliver.

------
jMyles
I surmise that hendrix, based on Twisted, will be the first true ASGI / Django
Channels backend.

~~~
retrogradeorbit
The problem with Twisted is that everything needs to be rewritten for it, like
a special snowflake. Hendrix is an example of that. The advantage of Django is
you can use any python library without issues.

~~~
jMyles
Really? I have exactly the opposite impression: that Twisted is happy to
consume any streams of data you provide, while Django is only happy if you
comply with the dictates of the LazySettings object.

In any case, I think you'll find hendrix unbelievably easy to use - here's a
talk that gives some detail:
[https://www.youtube.com/watch?v=92VeMkjM1TQ](https://www.youtube.com/watch?v=92VeMkjM1TQ)

~~~
retrogradeorbit
Yes, really. What if the library you are using uses blocking IO? What if it
reads a file using a plain 'with open("file") as fh:'? Now you've blocked
every connection in your twisted server. No warnings or errors, just strange
intermittent pauses on every connection leaving you scratching your head.

This isn't weird esoteric packages either. Ever used requests? SQLAlchemy?
Django's ORM? You can't use them with twisted.

Twisted proponents don't openly say this up front as it's not a great story,
and their response is usually "just" port the library.

Or maybe, put it like this. If Django and Twisted work well together, why does
Hendrix exist at all? Just use Django. Or why does klein exist? Just use
werkzeug. You'll see lots of this rewriting snowflakes.

Just a quick search gives me txamqp, txmongo, txmandrill, txflask, txcelery,
txdocker, txldap, txgithub, txrequests, txstripe, txzookeeper and on and on
and on. Have a look:
[https://pypi.python.org/pypi?%3Aaction=search&term=twisted&s...](https://pypi.python.org/pypi?%3Aaction=search&term=twisted&submit=search)

And then there's multiple ones of each to choose from. Look at amqp or reddis.
There's something like four implementations of each. Even something like
requests, theres treq, rxrequests, requests-twisted. Which one should I use?

And then there's Python 3. Only half of twisted works on Python 3. Which half?
I guess one finds out when they give it a go.

~~~
jMyles
> This isn't weird esoteric packages either. Ever used requests? SQLAlchemy?
> Django's ORM? You can't use them with twisted.

I'm left completely scratching my head here. I use all three of these packages
routinely with Twisted.

Are you saying that you are trying to share the reactor thread while blocking
with, for example, requests.get()? Obviously you can't do that - why would you
even try? Just run requests.get() on another thread.

On the other hand, if you, for example, use deferToThreadPool with a bunch of
Django ORM calls, you can happily go on serving requests from another
ThreadPool. This works like gravy.

These various adapters that you've described: in every case, their existence
is not a testament to an inability to run their respective libraries' blocking
I/O with Twisted; on the contrary, they provide support for actually using
them with a proper Twisted protocol.

The fact that so many of them exist doesn't mean that Twisted is doing
anything wrong, it means that people really like Twisted and want these
various packages to be able to talk directly to a Protocol or Producer without
having to maintain that code in their project.

If you want to run Django in Twisted without hendrix, go ahead: use the
WSGIServer built in Twisted. However, you'll probably find that you are
building lots of tooling around the _awesome things you want to do with
Twisted_ (ThreadPool tuning, websockets, concurrent functions running in
views, and much more). So, instead of having to write all that yourself,
hendrix ships with it.

For my practice, the Twisted ecosystem is the finest part of Python.

------
uryga
Channels sound pretty similar to Observables/Streams/Signals from the reactive
world. Weird that they didn't mention it.

~~~
andkon
From what I understand, Channels' provenance is from Go (scroll down to the
What is a Channel? section):
[http://channels.readthedocs.org/en/latest/concepts.html](http://channels.readthedocs.org/en/latest/concepts.html)

~~~
retrogradeorbit
"Go channels are reasonably similar to Django ones"

Really? Only at a surface glance. Having used channels in both Go and in
Clojure, I would say they are nothing like Django channels. The only thing
they share is they are like a fifo pipe.

In Go and Clojure channels are an in-process async construct. They have
nothing to do with the network at all. (There may be libraries that expose
their network connections in the language as channels, but the channel itself
is completely in process).

In these languages there is no 'routing' that needs to be set up. There is no
'linearisation' problem. They are first class and can be passed in and out of
functions.

Also most importantly, pulling from or pushing to a channel _appear_ to the
programmer as a blocking operation, while under the hood the language inverts
control to create a non-blocking situation. Send and receive on the Django
channels look to be non-blocking _and_ appear to the programmer to be non-
blocking (correct me if I'm wrong, please).

Saying all this I'm not opposed to calling Django channels, channels. Channels
is a generic term, and what is being done here in Django can be very much
described as a channel. Just remember that they are actually very different to
the "channels" as used in Go.

------
mozumder
Does Nginx support ASGI? What's the recommended production ASGI web server?

~~~
Wilya
The recommended ASGI server seems to be Daphne[0]. Nginx doesn't need to speak
ASGI natively (as it doesn't speak WSGI natively), more likely Daphne would
replace the WSGI server (gunicorn, etc) running behind nginx.

[0]
[https://github.com/andrewgodwin/daphne/](https://github.com/andrewgodwin/daphne/)

------
bkovacev
I love the chat implementation. What would the other possible usage scenarios
be?

~~~
cdelsolar
A real time game using websockets e.g.

------
hamiltonkibbe
Can we come up with a new word for this? Real-Time has a definition w/r/t
computing, and it's certainly not "Python code, running in a C runtime, on top
of a non-realtime OS."

~~~
LyndsySimon
I'd refer to it as just "asynchronous". I'm not sure why they felt the need to
redefine.

~~~
zokier
AJAX was already async (that's where the first A comes from..), so it makes
sense to have new name for new generation

------
lolosso
Way to go DJANGO

------
adaline
I assume this also means support for Rails 5's ActionCable.

