You can locate an "intermediary backend" on the client, write outstanding mutations into local storage, have a background worker send it to the backend, with necessary retries, etc. At worst, the background worker would put out a message about a failed update which the UI tread would receive and show.
But the happy path stays lightning-fast.
Sure but there's a ton of complexity in any kind of local-first syncing solution. Often the solution is CRDTs.
My point above is that the simple solution ("traditional CRUD app") is actually viable even when the goal is very low latency.
100% agree. A traditional CRUD app (like Linear) can be made pretty low latency without local-first. The complexity is not worth it.
How would you do it? The speed of light being what it is, and tail latencies being large unless you over provision wildly, you keep facing hundreds of milliseconds of reconciliation time, if you want guaranteed synchronous result.
I said it in another thread. Yes, of course we cannot match the local store interactivity. What I mean is coast to coast RTT is 65-80ms. And the server can be optimized to return back basic operations (adding a comment, a new ticket, reading one back etc) can be done within tens of milliseconds, keeping the entire thing under 100ms coast-to-coast. If one can colocate servers with users, it becomes even less. I'd rather to server side "reconciliation" than do both (because serverside thing doesnt go away even with localstore, it is just deferred).