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:
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.
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?
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.
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.
Related
I would like to create simple forum where users would be able to add/delete/modify posts stored in database. I have simple auth app: client(react app) - server(express). Is it possible to force client side to rerender for one user when there is a change made by another user while both are loggedIn?
It should be simple enough. When a logged in user is on a page that you want to keep synced, open a websocket to the server. Then, when any user makes a change, the server can update its database, and then once that's finished, it can send a websocket message to all users with connected sockets on that page, containing the new data to render.
In the client-side React, create the socket and subscribe to its message event. When a message is sent from the server, call the state setter with the new data.
This mechanism is somewhat similar to how Stack Overflow pushes "An edit has been made to this post" notifications when a post gets edited - anyone looking at the page will see such server-sent notifications through the websocket connection to Stack Exchange.
Websockets is one approach you can follow. If you think this will be complex to implement, you can poll for the data every minute or so.
This is very useful library tailored for React:
useQuery- https://tanstack.com/query/v4/docs/reference/useQuery?from=reactQueryV3&original=https://react-query-v3.tanstack.com/reference/useQuery
You can use it for polling/caching and making regular network calls as well. Lots of utility is provided that you can leverage; especially, considering the use case you seem to be tackling.
There is a slight learning curve, but its worth it if you're a react developer.
I have built a web application using AngularJS (front-end) and PHP/MySQL (back-end).
I was wondering if there is a way to "watch" the MySQL database (without Node.js), so if one user adds some data to it, the changes are synced to other users too.
E.g. I know Firebase does that, but it's object oriented database and I am unable to do the advanced queries there like I do with SQL.
I was thinking to use $interval and $http and do ajax requests, so that way I could detect changes in the database. Well, that's possible, but it'll then do thousands of http requests to the server everyday and plus interpret php on each request.
I believe nothing is impossible, I just need an idea to do this, which I don't have, so that's why I am asking for a help here.
If you want a form of "real-time communication" you'll likely have to incorporate some form of long-polling from the client. Unless you use web sockets, but that's a big post about a bunch of different things. You're right to be concerned about bandwidth and demand on the DB though. So here's my suggestion:
If you don't have experience with web sockets then log your events in a separate table/view and use the pub/sub method to subscribe entities to an event, and broadcast that event to the table. Then long-poll against the watcher view to see when changes may have occurred. If one did occur then you query for the exact value.
Another option would be to use some query system with "deciders" that hold messages. Take a look at Amazon's SQS platform for a better explanation of how this could work. Basically you have a queue that holds messages and a decider chooses where to store the message using some hash or sorting method (to reduce run time). When the client requests an update, the decider finds any messages that would apply based on the hash/sort and returns them. Then you just have to decide how and when to destruct the messages.
The second option would require a lot more tinkering though, so it's really about your preference. I think what you'll find the difficulty to be is that most solutions have to deal with the fact that the message has to be delivered 1 or More times and you'll need to track when someone received the message and if it can now be deleted from the queue/event table or if you still need to wait. Otherwise you'll consume a lot of memory.
This question isn't a code-level issue but merely a functionality question / brainstorm.
Within my PHP script I want to send a notification to another user in real time, there's 1 way I've thought of to do this, if you know any better ones be sure to leave them in the comments!
My idea for this functionality is to insert into a databse table with the user's id and the message, then on the user's end constantly loop a select request looking for notifications corresponding to their id within $_SESSION, if it's found a message then delete it from the table and display it to the user.
This seems like it could "strain" my database and I'm wondering if there's a cleaner way to do this, it would also be much appreciated if somebody could post a javascript loop with a 3 second delay and an ajax post to a php file within it,
Thanks all,
James
The cleaner way to do this would be with websockets. Polling, long polling, and streaming are going to have exactly the problem you thought you were going to have.
The message recipient needs to be listening via broadcast also through websockets. The server will notify all websockets listening for that particular event.
You don't want to block with database read and writes. Just take the action from one user and send it to all the other websockets listening for that event (the other user's client side instances)
For event history you would consider persisting to a database with a message queue.
With a properly indexed, well-structured table, it won't be a strain to the db at all. Of course, this assumes your interval is reasonable (3 seconds you mentioned is great). That's how all real-time session-checking websites work. Those that need more than that, such as chat systems, basically anything that passes data more frequently and/or in larger packets, they use websockets.
Use Websockets or Server-Sent-Events
just an idea:
User-1 send message to the Server {"message" : "hello", "target" : "User-2"}
Server checks the message and redirect it to the target User
User-2 listening for events from Websocket or Server-Sent-Events
I am currently developing a website where many users post topics and the associated topics' comments are shown in the page. Currently I'm developing using cake php.
The very first time a user clicks the website, all the topics and comments are displayed. But when other users add new topic or comment to a topic, I need to show the update in the same page. I am confused as in how am I able to retrieve new contents and update accordingly in a page. For instance how facebook does it where when your friends adds status or comments on your status, it updates without refreshing the page.
I know that AJAX technology is used but how is it done. Any source that I can refer? Hope someone can help as I have been doing research for the past one week but no answers so far.
You can go two routes in this.
Server Push
http://en.wikipedia.org/wiki/Push_technology
This technique is perhaps the most efficient as the server notifies the client of any updates. However this technique usually requires a bit more work than a simple polling system. You can use something like nodejs or Comet to push updates. If you're using nodejs, I highly recommend using SocketIO to handle the client side. With Socket.io you can have the client side listening to the server on a channel so that the server can notify the client whenever an update happens.
Client polls server
In this version, the client (new visitors browser) constantly polls the server for updates. You can set whatever gap you want, but keep in mind that if you make the polling gap too small your server might take a performance hit as each new user will create many requests. This method is as simple as setting up a setInterval() call in JS coupled with an AJAX call.
I have a online user list which is populated by a SQL query to a database table.
When a new user comes online, how can i make the webpage automatically update?
What code do I need to provide?
Thanks
There are a few ways you could do this, but I'll avoid the most tempting WebSockets HTML5 new-ness and suggest the following:
When a user logs on, record the fact that they are logged on to the database.
From your page, poll a service or web page method that lists online users.
If the list changes, update the part of the page that shows the users.
That's the rough outline of what to do. If you need specifics please say what server-side host and programming language you are using. From the client side, please also mention what JavaScript framework you'd prefer or are open to.