Why we developed the Node.js reference architecture

Introduction to the Node.js reference architecture, Part 1: Overview

March 8, 2021
Michael Dawson Lucas Holmquist
Related topics:
JavaScriptNode.jsOpen Source Communities
Related products:
Red Hat build of Node.js

Welcome to this new series introducing the Node.js reference architecture from Red Hat and IBM. This article is an overview of our reasons for developing the Node.js reference architecture—both what we hope the architecture will offer our developer community and what we do not intend it to do. Future articles will offer a detailed look at different sections of the reference architecture.

Follow our series:

Before we dive into this first article, it's important to acknowledge that the Node.js reference architecture is a work in progress. The development team is working through different areas, discussing what we've learned, and distilling that information into concise recommendations and guidance. Given the fast pace of development in the JavaScript ecosystem, the reference architecture might never be “finished.” Instead, we'll continue updating it to reflect what we learn through new Node.js production deployments and ongoing experience with our deployments at scale. The reference architecture is meant to reflect our current experience and thinking, which will evolve.

Why we need a Node.js reference architecture

The JavaScript ecosystem is fast-moving and vibrant. You only need to look at the growth rate of Node Package Manager (npm) modules to see that. In 2016, there were approximately 250,000 npm packages. In 2018, that number climbed to around 525,000, and in 2020 it was roughly 1.1 million. These numbers represent considerable choice and variety in the JavaScript ecosystem. That is clearly a strength for flourishing innovation and testing new ideas.

On the flip side, the wide variety of options can make choosing among Node.js packages very difficult. For any module, you might find several equally good choices, as well as several potentially very bad choices. Every application has a “secret sauce” that is key to its success. It is imperative to find the best fitting, newest, or most innovative package to use for this area of the application. For the rest of the application, you likely want something that works and for which you can share any experiences or best practices across your organization. In the latter case, having a reference architecture can help teams avoid relearning the same things again and again.

What is the reference architecture?

Our Node.js teams at Red Hat and IBM can't be experts on 1.1 million JavaScript packages in the npm registry. Similarly, we can't be involved in all of the projects to the level that we are involved in the Node.js project. Instead, our experience is based on our broad usage of Node.js. This includes large-scale deployments like the Weather Company, as well as the work that our consulting groups do with customers.

If every internal team and customer who asks for help with their Node.js application uses different packages, it will be much harder to help them. The question is, how do we share our knowledge across the organization?

We want to help our internal teams and customers make good choices and deployment decisions. In cases where a team doesn't need to use a specific package, we can recommend a package based on the experience we’ve built across Red Hat and IBM. As developers, we can use the Node.js reference architecture to share and collaborate across teams and projects and establish common ground within our deployments.

What the reference architecture is not

I have described what we hope to do with the Node.js reference architecture. It is just as important to be clear about what we are not trying to do.

First, the reference architecture is not an attempt to convince or force developers to use the packages we choose. Deployments are varied, and there will be good reasons to use specific modules in different circumstances.

Second, we do not claim that our recommendations are better than the alternatives. As I noted, you will often find several equally good packages or approaches available in the JavaScript ecosystem. Our recommendations favor what the Red Hat and IBM teams have used successfully and the technologies we are familiar with. We are not attempting to steer anyone to the “best” choice but instead to a “good” choice. Having a reference architecture maximizes the likelihood of leveraging lessons already learned and having common ground so that we can help each other.

About this series

The Node.js development team is having interesting discussions as we work through each section of the reference architecture. At the same time, we are trying to keep the reference architecture's content concise and to the point. As I've mentioned, the goal is to provide good choices for the application's general architecture so that developers can focus on the application's "secret sauce." In most cases, developers using the reference architecture will want to know what package or technology to use and how. As a result, the reference architecture won't include much about the interesting background and discussions that led to our decisions.

This series will share the viewpoints gained from our internal discussions. As we work through each section of the reference architecture, we'll use this series to offer additional references and an opportunity to dive into more detail on related topics. I think you’ll find the varied experience of developers across the Node.js team gets you thinking. I learn something from every section we go through, and I hope you will, too.

What’s next?

We plan to cover new topics regularly as part of this series. In the meantime, we invite you to visit the Node.js reference architecture repository on GitHub. You'll be able to see the work we've already done and the topics covered in this series. To learn more about what Red Hat is up to on the Node.js front, check out our Node.js landing page.

Last updated: August 1, 2024