[nine_k]

The user clicks the button, the mutation is stored in local storage. The user closes the tab, but it's not a problem.

A background worker picks up the mutation and sends it to the remote backend. It takes time, retries, etc.

Similarly, any errors reported by the background worker go to local store, and the next time the UI tab is loaded / activated, they are shown. A service worker can show a notification outright to let the user easily load the main UI. Normally this would be a rare occasion.

[blauditore]

1. What if the browser gets closed/killed? 2. Error messages around syncing issues are notoriously worse than those of a sync request to the backend that failed. So the UX in the end is worse.

More generally: You can't circument the trade-offs of a distributed database, which such products are, conceptually.

[ifwinterco]

Yeah this pattern can be made to work fine.

Main downside is it significantly complicates the front end code compared to just waiting for FE to sync with BE before updating

[galaxyLogic]

What if we had a local server running on the same PC, which then relays the request to some shared server on the internet?

[cwillu]

That's what a background worker is: a local server managed by the browser and only accessible to pages of the origin domain.

[galaxyLogic]

I'm thinking using a local http-server instead of web-workers . The local http server would do all the server-logic except also passing data that needs to be shared to a non-local server.