Re: [slightlyoff/ServiceWorker] consider allowing multiple worker thread instances for a single registration (#756)

We would like to use global state for service workers.  In my ideal world a service worker would be alive as long as and page accessing it is alive.

In developing mail clients, chat clients, and any app that has a more than trivial data layer, it's ideal to have a single source of truth for the data layer of the application.

Typically we want to store data in IDB, and layer business logic and in memory caching on top of that.  Before service workers we would use a SharedWorker for this, a single destination that services data requests from all the UI components.

In trying to add background sync with service workers, this model no longer works because a ServiceWorker cannot open and keep alive a SharedWorker.  Meaning the ServiceWorker has to duplicate the business logic of the SharedWorker, in a thread-safe manner.  The odds of any developer (let alone the average javascript developer) getting this right and not introducing data consistency bugs is incredibly low.

I think a better model for ServiceWorkers would be to behave more like SharedWorkers.  Live in the background as long as any page is open, or background sync is in progress.  If anything it is less resource intensive to keep the ServiceWorker alive while my UI is open, rather than have to spin it up repeatedly every time I make a request.  It also means that the ServiceWorker can be used to cache indexeddb data in memory, reducing the I/O load and increasing performance.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/756#issuecomment-237885471