Reputation: 1
In a node application serving websockets where users subscribe to several topics published and gets new updates on the topics in a real-time manner, whats the best way to store the topic-subscriber map?
Live Topics : Topic1, Topic2, Topic3, Topic4
User1 subscribes to Topic1,Topic2,Topic4. User2 subscribes to Topic2,Topic4.
So there shall be a map object as follows
Topic1=>[User1]
Topic2=>[User1,User2]
Topic4=>[User1,User2]
So that when there is an update on Topic1, the application shall pass the update on User1's websocket.
The question : Is it good enough to keep the topic-subscribers map as an application variable (javascript object)? Or is it better to employ REDIS to manage this?
I also want to store the information in this map to analyse for the trends like Topic interest over time by geography. Hence, this data shall be copied to the original DB in the background.
I believe I should not be querying the database to find the current subscribers everytime there is an update on a topic.
As with what I managed to find, REDIS is an in-memory datastore. And the javascript application variable will also live on the RAM.
Whats the best way to go about it?
Performance as in the quickest update to the subscriber is desired.
Upvotes: 0
Views: 214
Reputation: 4623
Personally I believe it is better to do this in Redis, but only because sooner or later you're going to need more than one node as your application scales. The moment you do that you're out of NodeJS-land and trying to find some way to coordinate this work across a cluster. Redis is very well suited to this task.
That said, perhaps you should look at the ActionHero framework. Its chat module does precisely what you're trying to do. With very little code you can have WebSocket clients connect to one or more nodes in a cluster (coordinated by Redis) and join zero or more chat rooms, then receive the messages sent to those rooms. It could save you some time.
Upvotes: 1