I'm sorry that almost a month as passed from the latest edition of Adventures in Nodeland. The last few weeks have been incredibly busy as I traveled across Europe (Dublin, Milan, Dublin, London) for multiple events, usually to promote Node.js, Fastify and Platformatic.
Lastly, Tuesday 21st at 16:30 GMT, I'd be hosting a masterclass to teach about configuring Node.js Applications without falling into common pitfalls.
In this edition you will find an analysis of the Monthly Node.js Downloads statistics, showing good trends and problematic behaviors!
Thanks for reading!
During the unofficial Node.js collaborator summit at NodeConf.eu, we found out we lacked data to make useful decisions on the usage of Node.js versions and operating systems.
I took some time to create a simple data visualization using Chart.js and Platformatic, available at nodedownloads.nodeland.dev (source code on github). The biggest news it that Node.js is not dying, in fact last September was the record month with 131 million downloads.
The first and most exciting point is that Node.js users do not upgrade. Last October (2023), Node.js v12 was still significantly downloaded (3.7 millions), as well as v14 (19 millions) and v16 (v39 millions): those release lines are all discontinued. Compare this to the download numbers of v18 (49 millions) and v20 (9 millions) and it's clear that most folks are running non-supported versions of Node.js.
It seems users install it once and forget it's on their system, until something breaks and they need to upgrade. Half of our downloads are for unmaintained versions of Node.js with known security vulnerabilities. How could we facilitate upgrades?
The second takeaway is that while Linux remains one of our major installation targets (likely for CI reasons), Windows usage is bigger than Mac OS X. We need more collaborators working on Windows. Would you be willing to help?
Thirdly, a small but consistent user base downloads our odd/non-lts releases. We need more feedback/testing sooner. Would you help ensure your application is not broken by our short-supported version?
Fourthly, headers account for almost half of our downloads, because headers files are needed to build native addons. This matches my gut feeling that almost all Node.js apps have a binary addon in their dep tree.
Deploying Node.js at scale is an art mastered by few. The most common problem is an exhaustion of resources that allows the application to denial of service itself. The result is Node.js systems that are massively overprovisioned, wasting enormous amounts of computing and memory - keeping most of them idle. In this talk, we will do some math, discover hard truths, and implement a fix.
How do you generate types dynamically? How do you write a script that creates some typescript code? The approach most people would recommend is to use Abstract Syntax Tree manipulations. I was working on a deadline to implement types for our OpenAPI client, and I would have missed our release window. I needed something different and more accessible to build. Luckily, a friend recommended a library I didn't know: code-block-writer. I fell in love with it at first sight.
Almost everybody has asked me what is the easiest way to deploy Fastify, and to quickly obtain an endpoint you can start testing against.
What if I tell you that you can have your Fastify application shipped to the cloud in 2 minutes? Let's take a look at our new command,
Can we use HTTP for communication within the same Node.js instance? Let's imagine a world where we can call fetch() to retrieve a local resource without hitting the network. How many lines of code would be required?
This talk describes the internals of Platformatic Runtime, Node.js Core fetch(), Undici and how they all combine to create an in-memory microservices network.
In the beginning, there were configuration files. Each environment had one committed to our repositories. Then, we discovered the light of the 12-factor applications and having environment-specific values set as environment variables. Then, NODE_ENV came along, and it broke our idyllic world.
Libraries with millions of weekly downloads check for NODE_ENV=production to enable optimizations, changing the behavior of applications. Given this worked so well, developers started loading configuration files (or secrets) based on the value of NODE_ENV to identify their "production" environment. However, what value should be used for the staging environment? What about QA? If we don't run the same code everywhere, we will be hit by bugs that we cannot reproduce across environments. So, we set NODE_ENV=production everywhere. How should we distinguish across environments, then? We took a look in this video
During one of the latest shows of JSParty, I did explain how AWS Lambda "cripples" Node.js by making it a significantly worse runtime. Here is a short excerpt:
This was picked up and commented by ThePrimagean on:
This last video got a massive popularity surge (90k views!), showing great interest in this topic. I would work on a deep dive video to explain things in greater detail.
In the meantime, you can read "Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%" by the team at AWS Prime Video.
pkgupdependency to support Bun.
referenceErroron schema validation failure.
'character and performance improvement.
hmacKeyonly mandatory with fastify/cookie
November 29th at the Bending Spoon offices in Milan, I will be speaking about "Networkless HTTP", sign up on eventbrite.