4 ms·
In the realtime stuff I've built I publish update notifications on different channels to Redis whenever data is saved from a model. Then I have a Node.js server
by jwarkentin 13y ago
In the realtime stuff I've built I publish update notifications on different channels to Redis whenever data is saved from a model. Then I have a Node.js server that listens for those update notifications, fetches the new update once, and then pushes it out to all connected clients. This reduces a LOT of load on the server because if we have 300 clients connected, it still results in only one request to the server to fetch the new data and update all clients.
Even if you don't want to use a pub/sub and publish instant notifications when data is updated you could implement polling in a Node.js server and just have all the clients connect to it with Socket.io. Then when the Node.js server sees an update in the data it can push it out to all the clients.
This strategy also has the advantage that you don't have to change anything on the client if you decide to switch to a pub/sub in the future for more real time updates.
- jconley 13y agoI've definitely done the separate channel thing in the past for update notifications and it does perform very well. Our setup is a pub/sub system, where the "sub" happens implicitly with the request for a resource via the GRIP proxy and protocol and the "pub" happens when we update our models as well. The proxy acts a lot like node.js and Socket.IO would, but simply speaks pure HTTP on our RESTful resources instead of the Socket.IO protocol over their transports.