Django Channels: From The Ground Up – Part 2


Last time, we decided to embark on a brave new adventure and give our Django framework a big upgrade with the inclusion of Django Channels. We got just far enough to get the development server running, but while this may be an adequate start, it’s better to develop against something like what we intend to deploy, right?

So, let’s go the rest of the way and get ready to develop against something that at least resembles a standard production-ready environment with Django Channels.


Django Channels: From The Ground Up – Part 1

You stare mournfully into the mass of code you’ve inherited. At some point, it’s clear, the requirements called for the server to push information to the client, because there’s an unholy mix of Server-Side Events, long-polling, hidden iframes and even a Java applet in there, all supporting some level of long-term connectivity with the server. It’s almost fascinating in its barely functional hideousness, and you would be inclined to leave well enough alone… except for the new feature specifications you’ve been assigned, which require the client to be able to send data back to the server in response to the received events, in as close to real-time as you can get.

It’s time for a major overhaul. Only Websockets can save us now. And, as it so happens, one of your favourite frameworks just added support for real-time, bi-directional communication…


Websockets for Backbone

Backbone + Websockets

Backbone’s had some of its thunder stolen lately by trendier frameworks like Meteor and Angular; for good reason, in most cases, as without the prosthetic functionality offered by the likes of Marionette, Backbone’s view handling (amongst a few other lacks and warts) is really just ‘roughed in’.

But the fact that a framework like marionette can be built on top of Backbone is a testament to Backbone’s flexibility – after all, as the name suggests, Backbone is really just the ‘skeleton’ of your app, and it’s willing to be fit into place however you need it to be.

For instance: Backbone’s default persistance method is via jQuery’s ajax – make a request to the server using one of the standard HTTP methods to persists changes to models in a collection to the server-side db. Works great, but maybe you need something faster/better/stronger/etc.

Like, say, WebSockets.