What Can Be Done to Strengthen the Node.js Package Ecosystem?
What Can Be Done to Strengthen the Node.js Package Ecosystem?
What can Node.js do better?
Join the DZone community and get the full member experience.Join For Free
I asked Michael Dawson, IBM Node.js Community Lead at IBM and the Node.js community Board representative, OpenJS Board of Directors, to dig into key Node.js topics to find out the state of package quality, making developing Node containerised apps for the cloud easier, and what Node events, as a long time member of the Node community, are coming up that are best suited for people digging into these problems.
There are a great number of packages available through the repositories and package management sites (for example npm and github). There are different levels of quality, support available and people are concerned about, issues with dependencies. What can be done to address this for Node users and the maintainers of those packages?
We have seen increased discussion in a number of dimensions that relate to this question. In my opinion 3 of the most important ones are:
- Projects/maintainers who need more help to keep their project moving forward
- Maintainers who want direct support for the work they do on important packages
- Node users, who need to better understand the level of help/support they might be able to get for packages they depend on and how they can manage the risk of using software they don't develop internally.,
You may also like: An Introduction to Node.js (Part 1).
In my opinion, one of the important areas that the package maintenance team has been working on is helping to share information which helps:
- Organizations understand and manage the risk associated with the packages they depend on.
- To surface gaps between expectations of a package maintainer and consumers of the package.
- To surface the ways that organizations can support the packages they depend on.
These are being addressed through the development of additional metadata that will capture the versions of Node.js (for example LTS versions) the maintainer plans to support in the future, the existing backing for the package, and how to support that package and finally what kind of support is available and the expected response. This is still a work in progress but you can take a look at the current state here.
I think this helps maintainers by enabling them to set expectations. For example, "I do this on the weekends so don't expect commercial level support.” It also lets them communicate the different ways that the project/maintainer can be supported.
I think this helps consumers by enabling tools to let organizations better understand the packages they depend on and hopefully be motivated to manage the associated risk by "helping" the packages they depend on. Help can come in many different forms including:
- Joining the OpenJS Foundation.
- Encouraging/paying their employees to join and contribute to open source projects.
- Directly supporting maintainers through something like the Linux Foundation's CommunityBridge, GitHub sponsors or one of the other options currently available.
- Buying support contracts with companies who do one or more of the above on their behalf.
In my opinion, it's important that consuming companies think about contributing back, especially on dependencies that they are using. These contributions will help improve the overall quality of packages and the speed and effectiveness with which issues can be remediated. In addition, and just as important, they will also help strengthen the underlying open source ecosystem supporting them.
The Node.js package maintenance team is also working to make it easier for maintainers to accept additional help and be more efficient by trying to figure out/document how to effectively accept help, developing suggested best practices, and helping to connect those that are interested in helping out.
I've been relatively focused on the backend and Node.js for the last few years, so I don't have as much insight into frontend frameworks. I'm hoping this changes going forward, as the OpenJS Foundation ramps up, and we have the opportunity for broader collaboration and knowledge transfer. (Editor’s note: The JS Foundation and the NodeJS Foundation merged to form the OpenJS Foundation in April 2019.)
What can be done to make developing Node containerized apps for the cloud easier?
When you deploy containerised applications to the cloud, startup time and memory footprint are often important. Startup time because following the 12 factor approach you will be starting/stopping/scaling many stateless microservices, so you want that to be fast. Memory footprint because often you are billed based on the size of the container you start. Node.js has done a good job on these two fronts so not too much needs to be done in that respect other than working to keep it that way. Community efforts like the Benchmarking WG and the nightly measurements of startup and footprint are part of that.
The second aspect of containerised deployments is the additional complexity of getting the data and artifacts that you need to be able to monitor your application and investigate problems. The Node.js community diagnostic working group is working on a set of best practices and one of the things that open source projects, solutions and commercial products should be doing is to help customers apply those best practices in product. This includes making monitoring easier, clearing pathways to getting artifacts for problem determination (for example, core dumps, heap dumps, logs) out of the deployed containers to the developers.
The last thing I'd want to highlight is helping developers and operations teams work together more easily for containerised deployments. The shift to containers has meant that developers often end up managing more of the infrastructure and plumbing than they'd like. At the same time the operations teams would prefer more consistent deployments so they are in a better position to help when needed.
What's needed are approaches that will allow the developer to focus on building the business part of the application and the architect/operations team to handle the infrastructure and deployment. On this front IBM has been supporting the Appsody and Kabanero open source projects. I think they are quite interesting, and I am excited to be working with some of our internal teams to use these project in IBM's development efforts.
What events can you suggest for Node developers?
In my opinion, there are 3 key Node.js events which include Node+JS Interactive, NodeConfEU and Node Summit. Those events have a strong focus on Node.js, what's going on in the community, and how to deploy Node.js in production each with different weighting on each. If I could only go to three conferences each year, those would be the ones.
The good news is that both Node+JS Interactive and NodeConf.eu are coming up in the next few months (December and November, respectively), so there is still time to register and take the opportunity to meet Node.js and OpenJS Foundation community members in person.
Adding to those conferences I would then suggest conferences which are focussed more closely to the technology a developer may be using but which also cover Node.js. For example, I've been to the last few POWERUp Conferences which are focused on the IBM i platform but which also have really good coverage for Node.js and Open source technologies.
Opinions expressed by DZone contributors are their own.