0

I have a Nodejs application which is using Mysql as a database, express and passport to manage user authentication. There can be 20-30 users connected to my Nodejs application at once time.

Now, there are certain pages in my application where multiple users can work on the same stuff at once. So if one user changes the value of the field, the other user will also see that change. As of right now to achieve this I am just using a Setinterval function that is running every 5 seconds with an ajax request post to the Nodejs server and then redraw the user field if necessary. This is working fine till now, but now I have decided, I wanted other pages in my application that I want to work this way. This means there will be multiple post backs happening to my Nodejs server every seconds to run mysql query. I am kind of new to Nodejs and I am not sure if this is an optimal way to handle this situation.

I was wandering if there is a way to send new field data to client, without client request and redrawing the DOM for them.

green coder
  • 55
  • 7
  • Event-driven updates from server to client? Sounds like a problem websockets could solve pretty well – Klaycon Jan 17 '20 at 23:41
  • Side note: no one I know of does concurrency management this way; the usual pattern is to reject on save if the old properties the user downloaded have been altered by someone else while the first user had them open for editing. In googlable terms it's called "optimistic concurrency" and would be a lot cheaper and more effective than implementing a system where the user sees someone else typing a new employee name into the same record they're editing the age of.. – Caius Jard Jan 17 '20 at 23:54
  • @CaiusJard - It sounds like you haven't used modern tools designed for simultaneous, multi-user use. Just look at Google docs where two people have the same shared document open. We can both be editing the document or one can see the other's edits in real-time. It's incredibly useful and is the more modern way to do collaboration rather than edit, save, send to someone else or edit, save rejected because of non-connected edits. – jfriend00 Jan 18 '20 at 01:03
  • @jfriend00 I think his point is that operational transform is really hard, and it's cheaper/easier to simply block updates to the wrong version of the document. Not that it shouldn't/couldn't be done. – Brad Jan 18 '20 at 01:07
  • @Brad - In the system the OP describes, they just want other editors to see changes that have already been committed to the database so they are always looking at the latest data in the database and so they are less likely to make edits when they were looking at old data that has been changed. This is a very desirable usability feature in many systems and should not be shunted aside because a more user unfriendly implementation is simpler to code. That's exactly how we get bad client/server applications. – jfriend00 Jan 18 '20 at 01:17
  • @Brad - Yes, you still have to protect against simultaneous edits and probably abort the changes by whoever came second (with an explanatory message), but a good system for updating others changes on screen as they are commited to the database prevents that from happening nearly as often (which is a good thing). – jfriend00 Jan 18 '20 at 01:18
  • @jfriend00 Oh, I don't disagree with you at all on those points. Just saying that I think CaiusJard is right to point out the rabbit hole. – Brad Jan 18 '20 at 01:21

1 Answers1

2

There are two solutions built-into the browser for the server to send data directly to a connected client.

  1. webSocket connections
  2. Server sent events

With each of these technologies, the client establishes one of these two types of connections on any given web page and then the server is able to send the client data whenever it wants.

webSockets are two way communication channels. Server sent events are one-way (data sent from server to client). Server sent events were designed to be a bit more efficient, but are more limited in what they can do.

It's important to realize that the lasting connection between client and server is only for the duration of that current page in the browser. If the end-user switches to another web page (even another page on your site), then the browser will close your current connection. If that new web page wants a similar connection, then it establishes a new connection on the new page.

With these types of connections from browser to server, your server then keeps track of each connection and some identifying information for each connection (like a username or userID). Then, when something changes in the data on the server, your server can figure out which clients should be notified of that change and send that new data over their connection. The client then receives that data and updates the visuals of the webpage using Javascript (displaying new data, updating status, etc...).

FYI, there is also a popular library called socket.io that works on top of webSocket and adds a number of useful features outlined here (such as connection failure detection, auto-reconnect, message passing layer, etc...). You would use the socket.io library in both client and server to add these features.

jfriend00
  • 683,504
  • 96
  • 985
  • 979