keyv
keyv copied to clipboard
jaredwray
Browser support
As mentioned in #64 , browser support would be useful . We're looking to run this in environments which are based on a web platform api (e.g. Cloudflare Workers).
Is there interest in addressing the two points of change mentioned in #64 ?
- Use https://www.npmjs.com/package/eventemitter3 instead of Node's built-in Event Emitter
- Use https://www.npmjs.com/package/buffer over using
json-bufferwhich relies on Node'sBuffer
@dremekie - thanks so much and I am adding this to a feature that we are going to look at in the next 90 days to implement. Do you have a use case that we can validate this against other than Cloudflare Workers? Would this help with other cloud providers serverless implementations?
I was just looking to see if there was a localStorage adapter and stumbled upon this ):
I was just looking to see if there was a
localStorageadapter and stumbled upon this ):
@alfaproject - make sure to upvote with a 👍 as we are evaluating if this makes senses.
I upvoted, thanks!
Client storage is getting increasingly more popular I think: https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Client-side_web_APIs/Client-side_storage
We are trying to do more and more computation at the edge and preferably at the customers browser so we offset resources to the client or as close to the client as possible and I think that's getting more popular, especially with the whole serverless thing (;
I upvoted, thanks!
Client storage is getting increasingly more popular I think: https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Client-side_web_APIs/Client-side_storage
We are trying to do more and more computation at the edge and preferably at the customers browser so we offset resources to the client or as close to the client as possible and I think that's getting more popular, especially with the whole serverless thing (;
Interesting. Why would you want to use Keyv instead of just talking directly to these storage providers?
Because depending on the environment I might want to load a different provider. For example, in incognito I would use memory adapter because localStorage is not available. If I need to save more than 5mb of data, I would switch to IndexedDB without changing any of my cache code. Likewise, if I want to update our Cloudflare workers, I can either use their KV cache or their durable objects stuff, etc
Also, in the back-end we already use Keyv, so having a unified cache interface across the stack improves DX
@jaredwray I'm looking to use this in serverless environments which have no NodeJS support. I think this library would be extremely beneficial within those environments as it provides a clean/well-tested layer of abstraction. Do you think this will make the "enhancement list"?
@dremekie - we are looking at how hard this would be and what compatibility issues we would see by doing this. Should have an update in the next week or so.
@dremekie @alfaproject - wanted to get an update to you. We found out that we need to do an architecture change on the caching layer before we make this work on the browser. Tracking it here: https://github.com/jaredwray/keyv/issues/407
To better support browser then i would wish for
- ESM
- use EventTarget instead of EventEmitter
- use Uint8Array instead of Buffer
- use Web standard CompressionStream / DecompressionStream instead for compression
@radman-x - this is still in planning for this year and we are first working on converting the project over to typescript. Once that is done then we will be building out the browser compatible version if possible. There is still some investigation on this.
Also, we are looking at ESM but the focus is to make it as compatible as possible first.
Hi All. This is now in flight and I am going to close this and you can comment on this issue moving forward: https://github.com/jaredwray/keyv/issues/868