Lightweight Django

Chapter 8. Communication Between Django and Tornado

In the previous chapter we created a Tornado-based server for handling websocket connections that can pass messages from client to client. In this chapter we’ll expand on that server to allow the Django application to push updates, improve the security of the websocket connection, and incorporate Redis as a message broker to improve the future scalability of the server.

Receiving Updates in Tornado

To prevent the race condition described in the previous chapter that occurs when tasks are dropped versus updated in the API, the Django server needs a way to push updates to the Tornado server. The Django server currently knows the location of the server via the WATERCOOLER_SERVER setting, but as previously noted the Tornado server manages all of its client subscriptions and broadcasts internally, so there is no way to broadcast a message from outside Tornado.

In later sections we will update the server to use Redis as a message broker for this broadcast. In that case, Django could publish the message directly to Redis. However, that would require the Django application to know the format of messages and how the messages are broadcast by Tornado, which would break our well-defined interactions between the two servers.

How do we solve this problem? In order to keep these applications independent, the Tornado server will expose its own HTTP API to receive updates from Django. When the Tornado server receives an update, it will translate the ...