Node.js Reference Architecture
The goal of the Node.js reference architecture is to present
teams 'opinion' on what components our customers
and internal teams should use when building Node.js applications
and guidance for how to be successful in production with those components.
Traditionally there has been reluctance to recommend a subset
looking to the
team for an opinion of where to start.
The components in this architecture are what we recommend to help internal and external customers get started based on our experience. Other components may be equally good, but these are the ones we know best and have the most experience with.
- Where possible the opinion is based on what we've used internally and in our customer engagements.
- Due to the above these are the components the
teamis best positioned when working with internal and external customers. However, we do not include formal support for these components in any of our support offerings unless specifically identified in those offerings.
- The recommended components may change over time as technologies and approaches change.
If you want to learn more about some of the discussions that went into the Node.js reference architecture you can check out the Introduction to the Node.js reference architecture blog post series.
team consists of engineers from across groups within IBM and Red Hat who:
- Whenever possible components should have been validated at scale within the
- We need to consider licensing and other due diligence when selecting components.
- We are going to start with a focus on the back-end, a similar effort for front-end components will make sense as a follow on.
The reference architecture covers the following components (currently a work in progress with only a subset of sections having recommendations):
- Typical Development Workflows
- Development Environment
- Choosing and vetting dependencies
- Building good containers
- Static Assets
- Protecting Code
- Code Quality
- Cross origin resource sharing (CORS)
- Secure Development Process
As a minimum, any modules recommended as part of this reference architecture should meet the following criteria:
- The module is not deprecated.
- The module has an appropriate license.
- Generally leaning towards permissive licenses such as MIT - others should be reviewed on case by case basis.
- The module runs on LTS versions of Node.js.
- The module has appropriate testing.
- The module is appropriately maintained:
- Regular releases (where appropriate).
- Critical bugs reports are acknowledged and addressed.
- Reported security vulnerabilities are patched and released.
To Contribute to this project, please see the Contributing Guide.
- Anthony Whalley - Technology Partner Architect - IBM
- Bethany Griggs - Sr. Software Engineer - Red Hat
- Carlos Santana - Senior Technical Staff Member - IBM
- Dominic Harries - Dev Lead at IBM Garage for Cloud
- Jim Lindeman - Sr. Software Engineer - IBM
- Joe Sepi - Open Tech Program Director - IBM
- Lucas Holmquist - Sr. Software Engineer - Red Hat
- Michael Dawson - Node.js lead for Red Hat and IBM
- Noel Madali - Web Architect - The Weather Company at IBM
- Tony Erwin - Senior Technical Staff Member - IBM
- Wojciech Trocki - Software Engineer - Red Hat