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

> Why do we feel that this thing will be faster than indexeddb? Depending on the design, we may be taking whatever hit per service worker wakeup, even if the data isn't needed.

I think the more realistic competition here is the https://github.com/WICG/cookie-store API.  In Firefox, `cookieStore.get()` calls will not involve any I/O for the foreseeable future.  Even if we took tips from spinning-disk optimizing-disk-defragmenters and tried to pre-heat the IndexedDB connection, IndexedDB would still lose every race.  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.

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.  You can do `(new URLSearchParams(location.search)).get("foo")` in your SW after having registered it via `navigator.serviceWorker.register("sw.js?foo=bar&baz=bop");` to synchronously get out "bar".  But that's only available to those willing to tunnel their SW configurations through a GET and deal with constant reinstallations of their SW whenever they want to update things.  But if we're willing to pay the storage price for the information on the registration there, why not make it slightly more ergonomic and let it be separable?

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.

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