How to architect a collaborative web application for live updates?

Question

When using collaborative applications like issue trackers, planning tools, etc. it can be very frustrating to have to keep hitting refresh to make sure you're viewing the same state as your colleagues. Therefore I want to build my applications so that when one user changes something, it shows up on everyone's screens. But I struggle to find good architectural discussions beyond "use polling" or "use web sockets".

I can imagine a few ways of doing it:

1. Use event sourcing throughout the application. User actions are sent as commands to the server and the server responds with events. The client maintains its own projection.

   Pros: Only one round trip of latency. All the benefits of CQRS.

   Cons: Complex logic for maintaining consistency, fetching snapshots, etc., both on the server and the client. While conceptually simple, event sourcing can be quite complex, especially for ad-hoc implementations.

2. A conventional server, but update notifications are sent to the client on a side channel. The client is then responsible for fetching the new data. A way of implementing this would be to build a conventional RESTful HTTP interface, but every time a PUT, POST or DELETE is made, clients receive the URL of the resource that changed, make another GET to it.

   Pros: Apart from the notification channel, it's a mature design pattern as old as the web itself, supported by frameworks, relational databases, etc. and easy for everyone to grok.

   Cons: Double round trip latency. Needs a message queue or something if multiple back-end instances are used.

3. When objects change, push entire new copies to the client. Instead of one-shot fetching, clients subscribe to resources. The server can be implemented according to either of the above strategies, with the associated pros and cons.

   Pros: One round trip latency. Very simple client.

   Cons: Could be wasteful to send a lot of big objects that the client might not even need.

Answer 1

I would solve the problem of having data that needs to be potentially updated separately from how it is persisted or how it is delivered to the client. So I would push the technical details a bit further, and come up with a design that lets me forget about the need to update.

For that I would use an object that encapsulates data that the client wants to keep track of and then just react to updates of it. Something like Android's LiveData, but more lightweight and monadic (i.e. it has map() and flatMap() to be able to work with it).

So when you have that, you don't need to manually track which pieces of data are on the screen. Instead, when you render that object into HTML, you emit the necessary javascript for the client, including what to do when it changes (could be even different depending on data). Whether that references a side-channel, or subscribes, long-polls, etc. doesn't matter for the server code.