web – Handling realtime notification receivers in a paginated application

I am working on an application right now, which is fully paginated. The application basically providers the client (a browser SPA) with a list of all data items other users added, and it does that in chunks of 50. So when entering the page, the user gets to see 50 items, and once scrolled to the bottom, 50 more items are loaded.

The items are not static, and the creator of a data item is allowed to change the item at any time, may that be description / name etc. – The exact change does not really matter.

When an update occurs, I’d like to keep the other clients who might have the updated data item loaded already up to date.

Now I’m wondering, how to do this.

I see a few options:

  • Don’t send any realtime update, wait for the client to receive new data when refreshing the page.
  • Send a notification through a websocket, so the SPA can pick it up immediately and update the item.

I am planning to go with the second route, but I’m a bit uncertain about how to best implement it.

Since I want the solution to be scalable, I don’t really want to send an update for every data item to every client, and apply it in case the item is loaded there, which would be the naive implementation. Safe to say, this won’t really scale well, since it’s a fan-out which might be unnecessary and discarded in a lot of cases.

In my opinion, the best solution would be to keep a mapping on the server, which keeps track of who has which data item id’s in cache. This should be done implicitly (When a client loads items, add their respective IDs to the client ID’s mapping), or explicitly (When loading items, the client explicitly sends a registration for the queried items).

Now I’m wondering, is this a good approach? What is the common approach for a problem like this?