Twisted and Django Channels

The following sections will dive into the structure of Django Channels and the technologies used in building it, and will try to tease out useful design details that can be used whenever you’re building complex multi-tier distributed applications intended

  • PDF / 150,721 Bytes
  • 7 Pages / 504 x 720 pts Page_size
  • 6 Downloads / 316 Views

DOWNLOAD

REPORT


Twisted and Django Channels Introduction The following sections will dive into the structure of Django Channels and the technologies used in building it, and will try to tease out useful design details that can be used whenever you’re building complex multi-tier distributed applications intended to scale horizontally. Python was one of the earliest programming languages to define a standard interface between web applications and web servers that wasn’t based on CGI, the Common Gateway Interface. CGI, while effective, was not particularly fast or high performance, so a need was identified to develop a richer interface between servers and applications, ideally one that took advantage of language primitives and features. In 2003 the Python core development team adopted PEP 333, which defined the Web Server Gateway Interface (WSGI). WSGI is an API specification that allows web servers that are capable of creating Python objects and calling Python functions (either from Python or via the C API) to invoke web applications in a standardized way. The goal of WSGI was to decouple web application frameworks from web servers, such that any web server can run any Python web application. From this perspective, WSGI was enormously successful. Most readers of this book will not remember a world before WSGI, and so the above description will seem perplexing: How could there be a world where web frameworks and web servers were not decoupled? In the post-WSGI world the Python community has seen a proliferation of great web application frameworks (such as Django and Flask) and great web servers (such as uWSGI, gunicorn, and Twisted) build on top of WSGI’s flexibility.

365

© Mark Williams, Cory Benfield, Brian Warner, Moshe Zadka, Dustin Mitchell, Kevin Samuel, Pierre Tardy 2019 M. Williams et al., Expert Twisted, https://doi.org/10.1007/978-1-4842-3742-7_12

Chapter 12

Twisted and Django Channels

However, it is not a perfect protocol. In particular, a WSGI server invokes a WSGI application by calling a synchronous Python function and blocking execution until it returns. This fundamentally synchronous invocation of a Python application in WSGI means that WSGI applications cannot easily be written in an asynchronous manner. At the surface level, this causes programmers some inconvenience: they can’t use Twisted or the async and await keywords. At a more foundational level, however, it makes Python web applications somewhat inefficient: each concurrent web request they handle requires a brand new operating system thread to process. The inefficiency of this approach is well-understood: after all, it’s part of why Twisted exists! Django Channels represent an attempt to allow Django applications to be written in a more concurrent manner, while retaining backward compatibility with WSGI applications. This is quite a substantial chunk of work, and so “Django Channels” actually cover a wide range of related technical projects. These include a new interface for server-to-application communication, the Asynchronous Server Gateway Interfac