DenoStore
cache-manager
| DenoStore | cache-manager | |
|---|---|---|
| 1 | 1 | |
| 87 | 1,355 | |
| - | 1.4% | |
| 0.0 | 8.8 | |
| 8 months ago | 2 days ago | |
| TypeScript | TypeScript | |
| MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
DenoStore
cache-manager
-
I finally escaped Node (and you can too)
If you've come from java and you like node, maybe you should spend some time with the alternatives?
A big part of it depends on what your exact requirements are but my experience with node didn't bite me for quite a while.
1/2) my experience is that even the supported packages have had glaring holes where they don't in other languages. Just to give a quick example, I had a project that used node-cache-manager to implement a tiered cache. There was a bug (in the cache library with the most stars) just last year where the cached values in a memory cache were passed by reference as opposed to copied. That meant any mutation on them affected other fetches from the cache! That would never happen in java. This particular bug took weeks to debug in production because values were being randomly mutated. After the fix, it also had different behaviour for when the cache value was new vs when it was retrieved. So two mutation bugs in the same cache codebase see https://github.com/BryanDonovan/node-cache-manager/issues/13....
I'm not blaming the author, he's a really good guy. What i'm saying is this is a wart both in the language and the library ecosystem - it's not unreasonable to expect a sensible caching library.
3) I agree that threads aren't necessarily the way to go. But can we agree that a language that CAN efficiently take advantage of multiple cores would be better? It's not just for your application. It's also for any compiling eg. typescript!
> Just check out the recent GitHub report where they were accidentally leaking information from other users into their sessions.
Concurrency is hard! except in a language where it isn't. In elixir each "thread" (erlang process) would get a different copy of the data so this type of bug doesn't happen.
4.
> Typescript (combined with autogenerating typescript type files from GraphQL schema definitions) has been honestly heaven for us, and the benefits I've seen with the structural-based typing of TS made me realize the huge number of times I had to battle the nominal-based typing of Java and the immense pain that caused.
That is an interesting assessment. I've never really noticed a difference in practice between structural/nominal type systems to the extent that i didn't realise typescript was structural. Normally if you have multiple classes implementing the same structure, you want an interface anyway to make sure they don't diverge i.e. there is a higher purpose for them being the same.
Would you have an example of how this would be a deal breaker?
I think besides this aspect, Kotlin might be up your alley.
What are some alternatives?
Deno-Redlock - Deno's first lightweight, secure distributed lock manager utilizing the Redlock algorithm
proposal-temporal - Provides standard objects and functions for working with dates and times.
r2d2 - Minimal Redis Client for Deno.
node-lru-cache - A fast cache that automatically deletes the least recently used items
FrameworkBenchmarks - Source for the TechEmpower Framework Benchmarks project
cacheable-request - Wrap native HTTP requests with RFC compliant cache support
axios-cache-interceptor - 📬 Small and efficient cache interceptor for axios. Etag, Cache-Control, TTL, HTTP headers and more!