I’m building a web-based productivity application that has to deal with modest user concurrency, and I’ve been exploring various options to keep the data in sync between the server and client. The application data is bootstrapped into JavaScript on page load, and websockets are used to push data to the server.
For a bit of context, I am currently using Node.JS and Socket.IO to create a persistent client-server gateway, which acts as a proxy to a Django backend.
The challenge is that I would like to keep all connected clients in sync with one another so that any change to the application on one client session is immediately reflected on all connected client sessions. The difficulty is that not all users are necessarily permitted to view all data; there are various different user levels, and different users can take ownership of slightly different sets of data.
Consequently, when an object is altered in some way and the change is committed to the database, I need to know which users of those currently connected I can safely push the data to.
I’ve been exploring different solutions to this and I feel as though this is something that can be handled through a pubsub messaging queue – using something like AMQP, but I’m struggling to figure out the structure of the application.
In my head, the application structure looks like this:
Client <–> Node.JS gateway <–> AMQP messaging queue <–> Django app
Should I just create a single direct exchange, treating the Node.js and Django instances as single clients, and then filter through the results somehow in Node.js?
Or is this sort of filtering something that the messaging system could handle, with each connected client subscribing to a relevant topic, for example, and only receiving the data they are permitted to see?
I’ve got very little experience working with messaging systems, so I’m struggling to get my head around what kind of role they are capable of within an application. Any advice would be greatly appreciated.
I think it will be much easier for each client to be subscribed to the relevant queue and just use node as a dumb gateway. Generally it is a good idea to push the security down the stack as far as possible. Also I think it will make handling easier if a client goes offline for a bit, as you can leave stuff in their queue and push it back later.