The Care and Upkeep of Node.js
Node.js is becoming increasingly important for IBM and clients
By Adam Oxford09/03/2019
Since its inception a decade ago, Node.js has picked up more than a few fans. It’s used because it’s fast, lightweight and very well suited for data-intensive applications. It’s emerging as a key tool for enabling the fourth industrial revolution and the cloud, ideal for capturing information from the Internet of Things (IoT), for example, and essential for the server-side operation of popular machine learning library TensorFlow.js.
As Node.js continues to mature—and increase in popularity—it has become very important for organizations such as IBM and its clients that it remains a cutting edge tool, but at the same time offers stability and security in use.
As Node.js has become a more critical tool for business, it’s increasingly important to ensure that it’s properly supported for IBM clients. One of the IBMers responsible for this is Michael Dawson, a senior product manager for Watson* IoT, and the Node.js community manager for IBM. It’s been very much a two-way relationship, he says.
“IBM’s strategy is to be highly involved with open-source software and be a good contributor to projects based on what our clients use,” Dawson says. “With Node.js, we need to have an enterprise-ready runtime, with enterprise-ready characteristics.”
“It was significantly more work than a normal port,” Dawson explains. “Because V8 has its own compiler—a lot of packages are written in straightforward C code so there’s a lot of very platform-specific technicalities that need to be taken care of.”
V8 also has a very fast release cycle, which means that maintaining the ports is a significant task in itself.
IBM has definitely had an impact on Node.js. And it’s important for us to be able to represent our customers and what they need in new releases.
IBM Support for Node.js
Being a “good contributor”, however, means more than just looking after your own. IBMers have played an important role in the Node.js community over the last five years. Gireesh Punathil is a worldwide service architect at IBM Runtimes, and a member of the technical steering committee (TSC) for Node.js. “The top priority should be how do we make Node.js sustainable in the enterprise,” says Punathil, “There’s been exponential growth, and many deployments are huge in nature.”
When IBM first got involved with Node.js, the community was young and growing fast—and experiencing much tension as a result. At one point, Node.js split into two separate forks, reflecting community frustration with the project.
Some IBMers were apprehensive that their work on porting V8 would be welcomed by the community. Those fears were soon allayed.
“The community was very receptive, because with these code changes in place, Node.js was working on two or three more major platforms,” Punathil says, “And that meant that they got new contributors to the community with system-level skills, which are rare these days.”
Those early issues are being resolved as Node.js has matured. The two forks have since come together; today, oversight for Node.js development and the community lies with the OpenJS Foundation. It’s committed to intense scrutiny of any changes to the core source code, and maintaining backwards compatibility has been essential to enterprise uptake.
The community has two key priorities for the immediate future, Punathil says: more coherence around the security of Node.js and better toolkits for performance benchmarking and diagnostics.
Managing Open Source
What makes Node.js appealing is that it’s capable, open source and free. But the very same qualities that make it exciting can also create challenges. The level of interest can be overwhelming—Node.js hosts the largest single repository of packages of any open-source project, with some 900,000 modules available in the Node.js package manager (NPM).
“It’s common to publish lots of small packages for specific reasons,” says Sam Roberts, senior software engineer at IBM Canada, and a member of both the security team and Security Working Group in the
Node.js community. “Developers treat the package registry as a function registry. They tend to have smaller packages and a lot more of them.”
A Node.js application may be reliant on a many other applications—or dependencies. “A rails app might have 20-30 dependencies,” says Roberts, “A node application could have 400-600.”
That means developers could be reliant on dozens of other people in the open-source community to keep their packages up to date and secure. It creates potential attack vectors: If a malicious actor manages to get their code in to a popular package, it could infect many other apps the next time they update their dependencies.
Much work has been done to improve the security and stability of Node.js in this regard, Roberts says, including the creation of a built-in auditing tool for NPM that looks for known vulnerabilities and warns developers of deprecated packages in their dependencies.
Things could always be improved, though, and one area of focus has been improving the way package maintainers are made aware of vulnerabilities as they are reported via the security team. In addition, work is ongoing to identify and support packages that are in use by business applications but aren’t being actively maintained.
One key achievement has been integrating better cryptography. Roberts was instrumental in building support for TLS 1.3 into the Node.js core.
Better Toolkits and More
IBM has been particularly proactive in the Node.js community in several other areas, says Dawson. One priority is developing and integrating developer tools for the runtime, to help with diagnostics and performance benchmarking.
“We’re also working on better documentation and best practice guides for debugging and investigating issues,” Dawson says, “My focus is on the ‘bigger picture’ things that Node.js needs going forward and how we can help with those. Not just ourselves, but enabling other contributors to make progress too.”
For example, work remains to be done on identifying whether enough people in the community are focused on specific issues, and where weaknesses in this sort of coverage lies.
Improving support for application distribution via containers such as Kubernetes is also important, and Dawson has also been part of a team behind a new API, N-API, for Node.js. N-API, Dawson says, makes development easier as it will allow packages to interact with new releases of the Node.js core, without needing to be recompiled.
One key achievement for the OpenJS Foundation (and its predecessor, the Node.js Foundation) is that the project now follows a strict release cycle with Long Term Support (LTS) versions that provide enterprise users with the time frames they need to plan around.
Bethany Griggs, a Node.js runtime developer at IBM, sits on the LTS Committee, helping to ensure new releases are stable and fully supported. She also works to identify and provide fixes for packages that customers are using but which aren’t being maintained.
“IBM has definitely had an impact on Node.js,” Griggs says, “And it’s important for us to be able to represent our customers and what they need in new releases.”
It’s a relationship that’s paying off for all.
Adam Oxford is a freelance writer based in South Africa. He’s covered technology-related issues for more than 20 years.
Post a Comment
Note: Comments are moderated and will not appear until approvedcomments powered by Disqus