Real-Time with Node.js: WebSocket + Server-Side Polling vs. Client-Side Polling

Question

I'm developing application that displays real-time data (charts, etc.) from Redis. Updated data comes to Redis very quickly (milliseconds). So it would make sense to show updates as often as possible (as long as human eye can notice it).

Technology stack:

• Node.js as a web server
• Redis that holds the data
• JavaScript/HTML (AngularJS) as a client

Right now I have client-side polling (GET requests to Node.js server every second that queries Redis for updates).

Is there advantage of doing server-side polling instead, and exposing updates through WebSocket? Every WebSocket connection will require separate Node.js poll (setInterval) though since client queries may be different. But it's not expected to have more than 100 WebSocket connections.

Any pros/cons between these two approaches?

Answer 1

If I understood your question correctly: you have less than 100 users who are going to use your resource simultaneously, and you want to find out what can be a better way to give them updates:

• clients ask for updates through time-out request (1 per second)
• server keep track of clients and whenever there is an update, it issues them an update.

I think the best solution depends on the data that you have and how important is for users to get this data.

I would go with client-side if:

• people do not care if their data is a little bit stale
• there would be approximately more then 1 update during this 1 second
• I do not have time to modify the code

I would go with server-side if:

• it is important to have up to date data and users can not tolerate lags
• updates are not so often (if for example we have updates only once per minute, only 1 in 60 client side request would be useful. And here server will just issue only one update)

One good thing is that node.js already has an excellent socket.io library for this purpose.