Django Channels alternatives

Django Channels (or just Channels) is a project that extends the Django framework. Channels is built on a Python spec called Asynchronous Server Gateway Interface (ASGI) which supports both synchronous and asynchronous programming. Channels enhances Django’s capabilities, so it can handle not only HTTP, but also WebSockets.  

Django Channels allows you to develop realtime functionality such as:

• Chat

• Multiplayer games

• Multi-user collaboration tools

• Polling apps

• Ride-sharing apps
  

We’ll now look at alternatives to Django Channels - similar technologies that allow you to build realtime functionality for end-users. Here are the five alternatives we’ll cover:

• DIY WebSocket solution

• Socket.IO

• Tornado

• websockets (Python library)

• Ably

WebSocket is a realtime technology that enables bi-directional, full-duplex communication between client and server over a persistent, single-socket connection.

A WebSocket connection starts as an HTTP request/response handshake. If this initial handshake is successful, the client and server have agreed to use the existing TCP connection that was established for the HTTP request as a WebSocket connection. This connection is kept alive for as long as needed (in theory, it can last forever), allowing the server and the client to independently send data at will.

• WebSocket is a mature, widely-used technology; it emerged over a decade ago and has been extensively battle-tested. Most programming languages, development platforms, and browsers support WebSockets. 

• The WebSocket technology allows for the implementation of application-level protocols (on top of WebSockets), and extensions for additional functionality (such as pub/sub messaging). Building on raw WebSockets means you have the flexibility of designing your own WebSocket-based protocol and capabilities, tailor-made for your specific use case and needs.

• Before WebSocket, HTTP techniques like AJAX long polling and Comet were the standard for building realtime apps. Compared to HTTP, WebSocket eliminates the need for a new connection with every request, drastically reducing the size of each message (no HTTP headers). This helps save bandwidth, improves latency, and makes WebSockets less taxing on the server side compared to HTTP.

DIY WebSocket solution cons

• Certain environments (such as corporate networks with proxy servers) will block WebSocket connections. You will most likely have to consider supporting fallback transports for these scenarios. 

• Unlike HTTP, WebSocket is stateful. This can be tricky to handle, because it requires the server layer to keep track of each individual WebSocket connection and maintain state information.

• Engineering a bespoke WebSocket solution that you can trust to deliver at scale is expensive, time-consuming, and requires significant engineering effort.
  

Here are some key stats to give you a taste of how complex it is to engineer WebSocket capabilities in-house:

• 65% of DIY WebSocket solutions had an outage or significant downtime in the last 12-18 months.

• 10.2 person-months is the average time to build basic WebSocket infrastructure, with limited scalability, in-house.

• Half of all self-built WebSocket solutions require $100K-$200K a year in upkeep.

Learn more about:

• Cost and complexities of building and maintaining WebSocket infrastructure

• The challenges of using WebSockets at scale

Created back in 2010, Socket.IO is a well-known open-source library that enables low-latency, bi-directional communication between web clients and servers. Socket.IO is built on top of the WebSocket protocol and provides additional capabilities such as automatic reconnections, or falling back to HTTP long polling. 

Socket.IO pros

• Multiplexing (namespaces), which enables you to minimize the number of TCP connections used, and broadcast support (rooms), to more efficiently distribute data to clients. 

• Disconnection detection (configurable Ping/Pong heartbeat mechanism) and automatic reconnections.

• Integrations with various solutions for horizontal scaling: Redis, MongoDB, Postgres, AMQP / RabbitMQ. Note that you have to use one of these when you scale beyond a single Socket.IO server, to pass events between nodes, and ensure that events are properly routed to all clients.

Socket.IO cons

• Socket.IO does not guarantee exactly-once messaging semantics. By default, an at-most-once guarantee is provided. Socket.IO can also be configured to provide at-least-once guarantees, although this brings additional engineering complexity  - you have to use acknowledgments, timeouts, assign a unique ID to each event, and persist events in the database. 

• Limited native security features - for example, Socket.IO doesn't provide end-to-end encryption, and it doesn't offer a mechanism to generate and renew tokens for authentication.

• Designed to work in a single region, rather than a multi-region architecture. This can lead to issues such as increased latency (if you have users in different parts of the world), and system downtime - what happens if the datacenter/region where you have your Socket.IO servers goes through an outage?

Learn about the pros and cons of using Socket.IO at scale

Per its documentation, “Tornado is a Python web framework and asynchronous networking library”. Tornado uses a non-blocking network I/O model, which makes it a good choice for applications that require a long-lived connection to each user. 

Tornado pros

• Comes with useful capabilities such as multi-protocol support (HTTP long polling, Server-Sent Events, WebSockets, and WebSocket subprotocols), payload compression, and configurable ping/pong frames. 

• It’s a lightweight and fast solution that’s known to scale to thousands of concurrent connections.

Tornado cons

• Much smaller developer community compared to Django Channels. While Channels has a rich ecosystem with thousands of plugins and a numerous and active community, there are not as many Tornado projects and tutorials to learn from, and there are significantly fewer addons/plugins you can use with your Tornado project. 

• Lacks features such as built-in authentication and database (ORM) support. 

websockets is an open-source library that allows you to build WebSocket servers and clients with Python. The websockets library is built on top of asyncio (the well-known asynchronous I/O Python framework) and provides coroutine APIs. 

websockets pros

• Multiple messaging patterns. In addition to 1:1 messaging, the websockets library allows you to broadcast the same event to all connected clients or a subset of clients.

• Claims it’s optimized for production, with configurable memory usage, and a robust mechanism to handle backpressure. 

websockets cons

• It doesn’t offer any fallback transports, such as long polling. While most of the time this won’t be a problem, there are certain environments (older browsers and some corporate networks) that don’t support the WebSocket protocol. If you expect users to connect from such environments, then the websockets library might not be a good choice for your use case.

• If you wish to run multiple processes, you will have to use something like Redis pub/sub to keep these processes in sync and pass events between them. Of course, this creates additional engineering complexity, and introduces a single point of failure - if your Redis server is done, your system will be severely affected. 

Ably provides managed realtime experience infrastructure and hosted realtime APIs to power multiplayer, chat, data synchronization, data broadcast, and notifications at internet scale. 

Key Ably capabilities

• A globally-distributed network of datacenters and edge points of presence.

• SDKs for every major programming language and development platform.

• Pub/sub APIs with features such as message delta compression, multi-protocol support (WebSockets, MQTT, Server-Sent Events), automatic reconnections with continuity, presence, and message history.

• Unified API for cross-platform push notifications.

• Integrations with streaming solutions like Apache Kafka & Amazon Kinesis, and serverless platforms such as AWS Lambda, Microsoft Azure Functions, and Google Cloud Functions. 

• Guaranteed message ordering and delivery.

• <65 ms roundtrip latency.

• Global fault tolerance and a 99.999% uptime SLA.

• Elastic scalability to handle up to millions of concurrently-connected clients. 

Here are some more resources for further reading:

• Learn more about Ably’s capabilities

• Explore Ably’s documentation

• Read customer stories to find out how organizations like HubSpot, Mentimeter, and Genius Sports benefit from trusting Ably with their realtime needs.