CacheStorage / localStorage or something similar needs to be included?

[XadillaX]

• https://www.w3.org/TR/service-workers/#cache-objects
• https://html.spec.whatwg.org/multipage/webstorage.html

I think those APIs should be included for supporting local KV features.

[maxshirshin]

This is definitely a topic to explore! Do you think we could split Web Storage and caches into separate issues? Each is a discussion large enough on its own, and they have very different use cases.

[XadillaX]

The first problem is should we define both of them? Or just choose one of them?

[jasnell]

This could absolutely be its own workstream. These do not yet meet the minimum requirements for inclusion in the minimum common API, however, as there is not a single already standard API that is consistent enough across the environments.

[XadillaX]

This could absolutely be its own workstream. These do not yet meet the minimum requirements for inclusion in the minimum common API, however, as there is not a single already standard API that is consistent enough across the environments.

I think we can open a new workstream to push this work.

[lucacasonato]

I think CacheStorage is a relatively well designed API, that would make sense to adopt in some form in the future.

localStorage however... not so much. I think if we want a unified KV storage API, it needs to at least be of async nature.

[exoticknight]

I think localStorage is much like a storage specified for browsers and not competent at universal storage.

[XadillaX]

I think localStorage is much like a storage specified for browsers and not competent at universal storage.

I agree. Maybe we can just open a workstream on CacheStorage related API.

Goal

Give Winter the ability of local cache. For scene like Serverless, edge, etc, many isolates (whatever in process or thread) of the same function (or application) can share their local cache in one container (or other environment). Just like the same origin in browser.

[jasnell]

I have not yet audited the Workers implementation of CacheStorage enough to know how much it varies from the spec but we do implement it and conformance to the spec is a goal. If Deno has plans to implement it, then I think a strong case can be made to include it in the common API. I don't believe there are any current plans to support the API in Node.js, however.

[fabiancook]

Deno has CacheStorage implemented, and Node.js has the in memory version of CacheStorage shipped already with undici, just not as a defined and constructed as a global.

The deno version mentions differences from the browser though:

How is the API different from browsers?

• You cannot match cache objects using by relative paths.
• You cannot pass options like ignoreVary, ignoreMethod, ignoreSearch.

https://github.com/nodejs/undici/pull/2076 https://github.com/denoland/deno/issues/2194

If we had CacheStorage as a minimum API it would be great, and then following to have optional persistence on them would be even better if we had Storage Buckets available