Intent to Implement: async local storage layered API
Domenic Denicola
Contact emails
dom...@chromium.org, hiro...@chromium.org
Explainer
https://github.com/domenic/async-local-storage/blob/master/README.md
Design doc/Spec
Spec: https://domenic.github.io/async-local-storage/
TAG review request: https://github.com/w3ctag/design-reviews/issues/278
Summary
Async local storage provides a simple, asynchronous key/value store with a modern API. Additionally, it allows easy creation of isolated storage areas beyond the default one.
Async local storage is a new layered API. It is layered on top of IndexedDB, storing its data in a specific database, so the developer can fall back to using IndexedDB directly when they need more advanced functionality.
Motivation
As explained in Mozilla's 2012 article, "There is no simple solution for local storage", the web today has no good key/value store. Local storage itself is synchronous, leading to performance issues and cross-window synchronization problems. Developers often use it anyway, leading to subpar web experiences.
Other developers use libraries like localForage or idb-keyval to get around this problem. We've taken inspiration from their work to build async local storage, which gives the platform these capabilities directly, even for developers who aren't able to hunt around npm for the best and latest storage capabilities. This is part of our layered APIs program, and our general attempts at fulfilling the second half of the extensible web manifesto where we standardize in high-level APIs by paving cowpaths.
Risks
Interoperability and Compatibility
This feature is early stage and implementing it is intended to give us insight into these risks as developers experiment with it.
One particular interoperability issue that will need to be solved before shipping is that, due to our layered APIs implementation strategy, currently author code that monkey-patches IndexedDB will affect the async local storage implementation. We are actively investigating ways of avoiding this; see drufball/layered-apis#6 for more details. (Note that the specification is written to avoid this interference; our implementation is the one at fault here, temporarily.)
Edge: No public signals. A web developer now working for Edge was pushing for async local storage in 2016 :).
Firefox/Safari: No public signals.
Web developers: Very positive; see links at https://github.com/w3c/IndexedDB/issues/91.
Ergonomics
This feature will sometimes be used in tandem with IndexedDB, for cases where more advanced functionality beyond a simple key/value store is needed. (See example.)
This feature will hopefully often be used to replace local storage usage.
Activation
Due to building on the layered APIs infrastructure, it will be relatively easy to polyfill. It uses no magic capabilities inaccessible to web devs today. And in the future when other browser support the layered API infrastructure, fallback to a polyfill will be easy using the built-in layered API fallback support. In the meantime, developers can use the layered API feature detection pattern and load their polyfills that way.
Debuggability
Because async local storage is layered on top of IndexedDB, it is easy to inspect the created databases in DevTools. Per spec, the created databases include the prefix "async-local-storage:", making them easy to identify as well.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/6428344899862528
Requesting approval to ship?
No.