In server-rendered app, there's nothing like UI state.
There's a request. This request and the database is enough to build response. There is no UI state. Your app can be (and often is) absolutely stateless and restult depends only on request and a state of the storage.
While when you have SPA, API & server, you lose the application state and it's not possible to store the whole app state in the client for many reasons (security, scalability, synchronisation...). So you have to store subset of it. And you have to build a machinery that will do all this synchronization so your states stay in sync. It's double the effort to get 5% improvement.
Of course there is.
For example, any state related to interactivity like forms, client-side validation, widgets, filters, etc.
Basically, I'm happy with my latency (for board games) which I hope to migrate closer to people as more edge compute offerings emerge. However, I'm wondering what the path is to find some of these ideas in more latency sensitive applications.
The explanation for how the net-code behind Overwatch is a good explanation: https://www.youtube.com/watch?v=W3aieHjyNvw
and I'm just trying to figure out how to build the reactive tree in a way to support it sanely.
1) Nothing bad can happen if we show some optimistic result before server returns, but server side will end up in different result.
2) Something bad can happen. Accordingly, for (1) we can do optimistic update, for (2) can't
Think about the nature of a document store, you put data in and data out. You gain concurrency by using compare and set such that multiple requests can compete, but this is expensive. First, you risk conflicts which require re-execution for the losers. Second, you must download the entire object, make a change, then write the entire object back.
The key to what I am doing is that I'm having the language take a message from a durable queue, integrate that message into the document via some code, then emitting a state change out. The client then subscribes to the document's parts to updates its UI state, and as the document changes, so does the UI.
The UI can be much more complicated while the server can be beautifully simple.
Only state shared between multiple clients should go to the server.