CODEWITHSUNDEEP
javascripthtmlarchitecturewebsocketsocket.io
Mik378
Mik378

Reputation: 22191

How to handle this typical case of WebSocket usage?

I wrote a web page where there is a zone for user's comments.
Any authenticated users could post a comment.

As many users could post comments almost simultaneously, I want the comments list to be auto-refreshed. Thus, I think about using WebSockets.

My thought are about a good/best practice for this use case:

  1. Once a comment is posted, should WebSockets process read the current comments list on database and send a Json response containing all the new comments? This would allow the client to directly append the new comments on the DOM (JS).
    Or should WebSocket just check the database (or queue if using a message queue (Redis, RabbitMQ etc..) for instance) and act just like: "Hey, I have new comments, click here if you want to see them !". This solution would only signal the presence of new comments, without bringing all those comments to the client. The workflow of retrieving the events would then involve by the client (by clicking on this sentence for instance) e.g using the traditional Ajax direction: client => server.

  2. It is highly possible that a user posts a comment, then navigates to another page of the website. Therefore, a websocket response containing the whole new comments would be useless. A simple notification would then be possible, as most of known websites do for instance with the "+1" counter or more relevant to the "comments" scenario: "1 new comment available".

Which way should I choose?

Upvotes: 0

Views: 456

Answers (2)

Brian McGinity
Brian McGinity

Reputation: 5945

I use a combination of both....

In some pages the websocket communication contains the actual data--sort of like a stock ticker update.

And in other cases, the websocket communication just says -- all users viewing xyz data--refresh it. And then the browsers performs an ajax to obtain the new data and the grid is smartly refreshed in such a way that only the changed cells are modified on screen using innerHTML and the new rows are added and deleted rows are removed.

In cases like stackoverflow, it makes sense to show a message, "Got new stuff to show--want to see it?"

When I establish the websocket in the browser, I pass a page Id in the url and the cookies are passed too. So websocket server knows--the user cookie and the page which is being viewed.

Then in the database (or middle tier logic) communicates to the websocket server with messages such as: This message is for users viewing 'xyz' page: smartly refresh grid 'abc'. And the websocket server broadcasts the message.

Because the protocol allows you to pass anything you like, you have the ability to make it anyway you like.

My advise it to do what's best in each particular situation.

Upvotes: 1

Angular University
Angular University

Reputation: 43117

I think to decide which data to push is mostly a matter of UI usability / user experience, as opposed to which technology is being used to interact with the server. We should avoid changing the UI with server pushed data in a way that would surprise the user in a negative way, for example having the comment feed constantly growing without any intervention from him.

But in the case of a realtime chart, it's probably better to push the data directly into the chart, that would be what the user expects.

In the case of the comment feed the reason why most sites go with the 'click to load' approach is because of user experience, so I think that is probably the best approach.

Upvotes: 2

Related Questions