Async Iterators fun, a security vulnerability - Adventures in Nodeland - Issue #10
Hi Folks! Another week as passed and I’m going to list what I saw happening in Nodeland. First, we have an interesting puzzle with AsyncI terators, then a few bits of content, a (tough) security vulnerability with CSRF, and a job post that list Fastify as part of their stack! I really like this issue, I hope you can enjoy it as well.
I have always been a huge proponent of Async Iterators as a standard way to model streaming data. Async iterators are easier to understand and use compared to all the streams primitives on both the Web and Node.js. Even if they are simple to use and create, you still need to be aware of what is happening underneath.. as all I/O abstractions are leaky. Read up in this twitter thread:
Why is it relevant? The snippet above assumes that each async iterator could be completely disposed by the garbage collector. In Node.js, this is not the case if the async iterator wraps a native resource, such as a file descriptor, a Node.js Stream. Therefore, you need to manually dispose of files and sockets (and any other native resources).
Why was Node.js implemented in this way? The garbage collector is non-deterministic, therefore it’s not possible to rely on it to close native resources as soon as they are out of scope: if we supported this case, they could be left lingering in memory for a long time, leading to hard to debug “EMFILE” errors (the kernel error that is returned if the process cannot create more files).
You can also read about the Node.js core issue that spawned this discussion here:
If you want to dig deep on how use EventEmitter and Streams inside async/ await, I recently did a talk about it: “The unsung hero story of Events, Streams and Promises”.
|
OpenHive.js
A few months back I had to opportunity to interview the fellow Node.js Technical Steering Committee member Danielle Adams.
|
|
|
Fastify
Fastify made the news recently when it became part of the standard templates of Glitch. The key reason? It’s plugin system. Read mode at:
I have recently released as fix a for a long-time security vulnerability in fastify-csrf when using the technique called “double submit”. This vulnerability only affects users that are running fastify-csrf on several subdomains. Read more.
To ESM or to not ESM?
We are 5 months in 2021, and the question that burns me the most is… when should I start migrating my modules to ESM? Should I? I think I should wait for the loaders to be out of experimental, however folks are asking for an ESM version of https://www.npmjs.com/package/fastq among others. What do you think I should do? I’m considering using a dual package:
|
|
|
Jobs
This week I am trying a new experiment, sharing a job offer from a company that is looking for an engineer to work on a Fastify backend. My friend Ahmad Nassri is CTO at #paid - a platform that sits at the intersection of creator and brand collaboration. They are looking for a full stack engineer to build their Fastify application!
Thanks
That’s all for this week! As usual, I would not be writing this if it wasn’t for you - keep your feedbacks coming, open issues and contribute back to Node.js!