Hacker News Reader

Comment by mohsen1 | Hacker News Reader

Works for Linear because the tab stays open, and worse case if tab is closed you can recover later when the tab is opened again and deal with conflict resolution. Won't work if:

1. user clicks a button and closes the tab thinking transaction is done and it's important that transaction is done

2. conflict resolution is difficult or impossible in future client wake up

View on HN

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.

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.

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

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

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

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.

Yes and for linear (if you break it down strictly in a theoretical CS sense, is roughly equivalent to TodoMVC in terms of application complexity assuming non-collaborative text editing) they have clearly defined states for most items and few if none truly destructive actions. The hardest part is anything text related.

Expose the sync queue to end user and train them to understand if they attempt to close the tab with a pending queue they will get the ugly prompt warning them

Still works if you use beacon requests, they survive tab close

Bear in mind that beacon is something of a hail Mary, though. No way to tell if it was successful or not or react if it wasn't.

Reply on news.ycombinator.com