Use-case

[lorikku]

Hello there! I want to start off by saying that this looks insane and a job well done. I don't mean to be rude in any way whatsoever when I'm asking this question, but I just wondered, what would be a use-case for this library?

I don't have a lot of knowledge about caching so that's likely the main reason why I don't understand the benefits of this library. I just wondered, aren't JS variables also stored in memory? What would be the difference with storing values in variables on the fly using let or objects? What are the benefits of using this library?

I simply just want to learn! 😄

[jelveh]

Well, the sweet spot would be "when you need caching but running Redis/Memcached would be an overkill". For example, in puter.com we utilize it for rate limiting etc., and by using KV.js we don't really have to bundle Redis with the codebase (or Dockerize it).

[ama-coder]

its my question to.i think its not the answer.... whats the difference between this and js variables. is it global or something (can yo use it values on a foreign app)
but i like to help in dev proc

[lorikku]

That's indeed not the answer. I want to know what the benefits are of using this caching library over just storing values in variables/objects (which are also stored in memory either way). It's not about kv.js vs Redis/Memcached, but rather about kv.js vs native variables or why using an in-memory caching library is worth it at all over variables?

[jelveh]

You're right, I missed the part about kv.js vs variables.

For simple set, get, del,... using variables is the obvious choice. Things get a little redundant when we need expire, expireat and other secondary operations where, for example, we need a loop to check for expiry and "garbage collection". Before kv.js I had to re-write these for every use case e.g. rate-limiting, token caching, etc. so I just abstracted these parts away into a class called kvjs.

There is also one more thing to note, expire, ttl... seem simple on the surface but in order to do them efficiently we need to do a lot of non-trivial optimizations (e.g. the check interval should be as long as the shortest ttl). This is not currently done in kv.js but I plan to implement them over time, I think that's also one way kv.js could potentially prevent others re-writing this stuff from scratch.

Additionally, I wanted to use this super popular library with 3m weekly downloads which seems to be abandoned for years, so I hope kv.js can become an actively-developed, well-supported alternative.

I'm hoping this helps save a little bit of development time for others as well.

[ama-coder]

its seems like great :).

[jelveh]

Thank you :)

[KernelDeimos]

I'd like to add to this, having a Redis-like api right off the bat makes it much easier to move to Redis later if your requirements for scaling and distribution change. You can use the TTL/expiration mechanisms just like you would in Redis and then it's not a huge refactor to make the switch.