You are not updating Node.js

Hi Folks,

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.

In the meanwhile, Platformatic usage has been skyrocketing, and now we are close to 10k weekly downloads! If you want to learn more, check out our website and our docs.

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!

Matteo

You are not updating Node.js

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.

Talks

Do not thrash the Node js event loop

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.

Generating Types without Climbing a Tree

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.

The Easiest Way to Deploy Fastify

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, platformatic deploy.

Networkless HTTP

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.

NODE_ENV=production is a lie!

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

Look, Mum, I'm famous!

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.

Releases

• @fastify/sensible v5.4.0 improves type declaration for errors.
• pino-elasticsearch v7.0.0 Support elastic client 8 & drop old Node.js versions.
• @fastify/autoload v5.7.2 adds FASTIFY_AUTOLOAD_TYPESCRIPT environment variable and removes pkgup dependency to support Bun.
• json-schema-ref-resolver v1.0.1 throws more informative error when cannot resolve ref.
• @fastify/postgresql v5.2.2 fixes a referenceError on schema validation failure.
• mercurius v13.2.0 make URL dynamic so even if the GraphiQL is deployed on baseUrl it can work. v13.2.1 fixes a minor regression. v13.2.2 fixes another. v13.3.0 supports passing options to graphql validate and parse.
• @fastify/sensible v5.5.0 export httpErrors.
• @fastify/postgres v5.2.1 fix broken test and dependency updates.
• pino v8.16.1 support for Node v21.
• undici v5.27.0 feat: forward onRequestSent to handler
• @fastify/env v5.2.1 correct expandEnv bug when passing in a new object in the data option.
• mercurius-gateway v2.1.0 handles gzip compression in response body.
• process-warning v2.3.0 adds createDeprecation method.
• @fastify/aws-lambda sets the type to commonjs.
• pino-http v8.5.1 use Pino options generics.
• fast-json-stringify v5.9.0 serializes constants with ' character and performance improvement.
• @fastify/csrf-protection hmacKey only mandatory with fastify/cookie
• mqtt-packet v9.0.0 drops old Node.js versions.
• single-user-cache v1.0.0 drops old Node.js. v1.0.1 fixes concurrent request support.
• @fastify/cookie v9.2.0 goes back to use our own cookie implementation, and it adds partitioned support.
• @fastify/etag v5.0.0 makes sha1 the default algorithm
• pino v8.16.2 typescript fixes
• @fastify/aws-lambda v3.5.0 reflects remote IP address.

Artciles

• Goodbye Node.js Buffer - I personally don't think so. Are you planning to?
• Mercurius and Apollo interoperability. Check out this great benchmark on how to integrate Mercurius with Apollo Gateway!
• Read the Mercedes-Benz Open Source Manifesto. More companies should follow their lead.
• HTML web components - Do you plan to start using Web Components soon?
• Using JWTs to Authenticate Services Unravels API Gateways.
• Deprecation of ESLint formatting rules
• Why GraphQL Needs an Open Federation Approach

Events

November 29th at the Bending Spoon offices in Milan, I will be speaking about "Networkless HTTP", sign up on eventbrite.