Agreed. It becomes really messy moving all that state around.
Still in its infancy but we’ve settled on a model where we use Hasura to sync the whole datastore to the frontend as a mobx graph. It’s relatively easy to then drive the frontend off layers of computations on that graph. We’ve also put a transaction layer on mutations of the models so they’re automatically batched and sent as a single request / dB transactions.
It’s liberating to get to a place where I can just update models in the frontend and have that reflected everywhere because, as you point out, there’s enough to coordinate in all the bits you have to mutate.
Edit: we borrowed the idea from how linear.app does it
The clients are all up to date on changes fairly much instantaneously. And then updates from a client are synchronous in terms of setting all data and having that bundled and sent as a single request which is executed as a single dB transaction (we only send the specific fields that were updated).
If two people do something at the same moment, then it’s last request wins. We have dB constraints to keep the data consistent.
It’s not a perfect model, but it’s pragmatic and works well for our use.
Still in its infancy but we’ve settled on a model where we use Hasura to sync the whole datastore to the frontend as a mobx graph. It’s relatively easy to then drive the frontend off layers of computations on that graph. We’ve also put a transaction layer on mutations of the models so they’re automatically batched and sent as a single request / dB transactions.
It’s liberating to get to a place where I can just update models in the frontend and have that reflected everywhere because, as you point out, there’s enough to coordinate in all the bits you have to mutate.
Edit: we borrowed the idea from how linear.app does it