In-process caching and other Adventures in Nodeland - Issue #19
Hey Everyone, this is a new edition of Adventures in Nodeland that focus on… Caching! We will cover an old module, a couple of new modules, and a few interesting articles. Enjoy!
|
|
|
I’m always surprised when I go back to an old module and see how well engineered something is. In this case, I would like to cover fastify-etag.
ETags are a key part of the HTTP/1.1 caching mechanism https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html. ETags are hashes that are computed as part of a response, then then they are sent back for subsequent requests: in case the hash matches, it returns a 304 and no content.
The most important part for deploying ETags at scale is how fast it can compute those ETags. Using a cryptographic hashing algorithm like SHA1, SHA256 can significantly increase the CPU load of our Node.js processes.
Not one, but two caches
Last week I spent some time researching new pattern for implementing in-process caching. Why is this important? Shouldn’t we just use Redis or Memcached for caching? They would add only a few milliseconds to the overall response time (watch my talk at RedisConf on the topic https://www.youtube.com/watch?v=0L0ER4pZbX4).
In process caches have the key advantage of completely removing even those few milliseconds, making deployment simpler (one less component) and more resilient (no central cache). The downside of this approach is that data could easily get out of sync between servers. However this is how HTTP caching works… and it’s generally ok for customers.
Anyway, the first cache is InfiniCache: a cache that rely on WeakRef and FinalizationRegistry to cache things in the process memory, up until a garbage collection cycle happens. However this cache does not perform really well: for example mnemonist LRUCache is an order of magnitude faster (https://yomguithereal.github.io/mnemonist/lru-cache.html).
|
|
|
The second cache is significantly more useful, meet async-cache-dedupe. This cache allows you to wrap an async function and it make sure that any calls will be deduplicated for the same parameter: you will not be fetching the same data twice from the database in a given time slot. Check it out!
|
|
|
Tests, tests, tests..
In a new episode of OpenHive.js, we cover Testing as a main topic with Yoni Goldberg, the author of https://testjavascript.com/. Check it out!
|
|
|
Interesting Articles
I have often though that Github Sponsor was a significant issue for managing own taxes in Italy - I have been so scared to figure it out that I did not even try. The following is a really good writeup for how the Sweden government taxes the proceedings of Github Sponsors.
Recently I researched how Fargate worked. I was extremely surprised when I read that they moved to firecracker (https://firecracker-microvm.github.io/), the micro-vm technology that powers AWS Lambda. This is a really interesting read:
I am hearing different opinions on Github Actions from different friends: for some it’s not reliable enough… for others is such a fundamental piece of tech to migrate 4000 github repos. As of now Github Action is my CI of choice, even if it’s not always reliable the simplicity of use and configuration makes is a no-brainer. What do you think?
Fastify
My friends at Prisma have created a page dedicated to Fastify! Check it out:
|
|
|
NearForm
I’m a bit sad to announce that my colleague James Snell is leaving NearForm. I’m also incredibly happy for him as I know he would build amazing new things at his new job… he is definitely not leaving the JavaScript community! Anyhow, we are hiring a Node.js Core Engineer:https://grnh.se/5c39f3d43us.
Thanks
As usual, thank you so much for reading through my rumblings! Let me know if you have any question!