Introduction to the Node.js reference architecture, Part 1: Overview
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.
Why we need a Node.js reference architecture
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 the reference architecture is
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.
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.
We plan to cover new topics regularly as part of this series. While you wait for the next installment, 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 kinds of topics you can look forward to from this series. To learn more about what Red Hat is up to on the Node.js front, check out our Node.js landing page.