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.
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 ...