Re: [w3c/ServiceWorker] A simple globally available store of data per-registration (#1331)

@jakearchibald some more use cases:

## Expiration date or timeout for a service worker
Goal here is to create a safeguard against a service worker operating too long or forever. On install, the service worker records an entry in the store noting the version (string uniquely identifying the version, embedded in the script) and the current timestamp. Then, on `fetch` (or any functional event), the service worker checks the timestamp in the store, associated with it's version. If the timestamp was too long ago, the handler exists early and is essentially a no-op. Variations here: it might be more useful to record the timestamp in the activate step, though I think this would be more challenging to allow writes during activate. It might be nice to have the store be per-version, if we decide that there are enough use cases that are specific to service worker versions.

## Throttling or debouncing
In order to throttle an operation, you need to know the last time it happened. Let's say you want to implement some sort of heartbeat or need to check the server regularly for something. You could do the check on every `fetch`, but this would be way to noisy. So you could throttle the check that is kicked off by `fetch`. We tried doing this with IndexedDB, but IndexedDB was far too unreliable. This use case would require allowing an active worker to make writes, which would complicate things.

## Cache pointers
Consider a single service worker that handles requests for multiple applications. You might have multiple apps on a single domain, or you might serve a different app at the exact same url, depending on network speed or locale. Or you may simply want to be able to update the app immediately without having to always use `skipWaiting()`. At this point, the service worker as more of a generalized traffic server for a domain, deployed to browsers, rather than a tightly coupled part of a particular app. Thus, the upgrade lifecycle of the app(s) is separate from the install/activate lifecycle of the service worker. So the service worker would have to orchestrate updating the cache with a new version of a certain app, all while active. You could do this by keeping a reference to the active cache. When a new version of the app is detected, you populate a new cache, and once the new cache is ready, you change the pointer to point to the new cache and delete the old cache. Such a feature would require allowing an active worker to make writes. 

## Feature flags
You want to either run an A/B experiment, or be able to turn on/off a feature, without going through the normal install/activate cycle. There are a number of ways to implement, but there would need to be some sort of server endpoint that provided the latest feature flags. This endpoint could be called periodically 

The last two use cases boil down to being able to make adjustments to behavior without going through the normal install/activate phase. This is needed when you don't want to use `skipWaiting()` all the time, but you want some changes to be immediate.

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