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

@jakearchibald The use case is changing the sw behaviour without having to release a new version. We have a feature flag system which enables us to roll out any new feature and QA it in production by means of setting a cookie, which then sets headers, template state etc, propagating through the stack for that user's requests only. Having this available for QAing service workers is useful too, so on page load a message is sent to the SW to tell it which flags are on, and caching & retrieval of responses is conditional on the state of the flag.

If there was guaranteed to be one sw that didn't die then the posted message would be enough. As that isn't the case, storing the flag state in IDB to be retrieved on startup of the worker is necessary. Then, when handling fetches, it would be possible to read from IDB for each fetch request, but that seems like a performance nightmare - I don't know much about IDB perf, but I can't imagine calling it for most fetch requests would be good. Polling IDB to pick up any flag updates that may have been posted to another sw instance, so that the flag state can be read from a local variable, is a good enough compromise.



---
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-238025928