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

> I do think browsers should optimize IndexedDB, but realistically, hacks like abusing cookies will catch on if they're the easiest path to consistently low latency.

I agree. For instance, we have been experimenting with using `Cache` as a key value store. URL is the key, value is put into the response body as a string. It's a hack, but it works better than IndexedDB.

> Implementation-wise, in Firefox, I think we'd throw my ugly proposal on the registration. Because the reality is that what I proposed above is already available.

Sounds like a great start. For our needs, it would be nice to eventually have a store that is writable from the install hook of the service worker. So that we can implement a timeout/expiration date specific to each version. i.e., once a version is installed, it can only operate for a set amount of days.

> Also, a related factor that I expect weighs heavily in requesting synchronous access is that not invoking respondWith() in fetch both looks and actually is faster than pass-through fetch in many cases. No matter how fast we make the async operation, it's not going to look as fast as never going async in the first place.

Makes sense. I'm curious as to if there any cases where not invoking `respondWith` is actually slower, and on average, how much faster is not invoking `respondWith`, compared to pass-through fetch.

To be clear, I don't really care what the final solution is, as long as it provides a fast, reliable way to persist a small amount of information that can written to from the window scope and from the install step.


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