Comment by nfw2

As for your question about persisted data, yeah it definitely needs to be modeled on the backend, right? How much modeling should be done on the FE is a good question. This question is sort of why GraphQL exists. GraphQL provides a contract between the backend and the frontend about what the data sent between the two needs to look like. Apollo provides a pretty good and easy-to-use GraphQL implementation in my experience.

As for real-time updates, this hasn't been a real concern in most of my professional work. If I needed to support this, I think what I would do is:

1.) Define a clear set of actions for everything that needs to be streamed to users real-time (IE, I wouldn't try to stream the full state tree itself, this is where conflicts would arise)

2.) Determine how each action mutates the graphql tree

3.) Add a process that watches for these actions at the top of the React tree and manipulate the GraphQL cache as necessary in response to the incoming actions, (coming from a WebSocket connection, for example).

If you stream the actions, you may be able to resolve simultaneous edits naturally. Or, if you really want to block simultaneous edits, I think you should 1.) definitely ensure the edit is really blocked on the backend, and 2.) stream on "disable" action to the user via webso