Background You may have noticed N-API changed to Node-API in the documentation within the Node.js project. N-API has always stood for Node-API but was often pronounced NAPI. A concern was raised, that when pronounced that way, it could be mistaken for a derogatory term. We therefore made it our goal to clarify that N-API is Node-API whenever possible without introducing breaking changes.
What’s changing (only in more recent versions):
References: Documentation, blog posts, and similar will now refer to “Node-API”.
Folders: Internally referenced folders (eg. test folders) have been renamed from n-api to node-api.
Badges hosted on Node repositories: Existing badges’ image contents have been updated to “Node-API” without changing their URLs.
New symbols: Additions to Node-API and related projects will now have a different prefix, eg. node_api_get_module_file_name.
Types, macros, and defines: Externally-facing API names, such as features guards, will now start with NODE_API_ instead of NAPI_
New node arguments: Node-API configuration via node command line arguments, eg.- -force-node-api-uncaught-exceptions-policy, will refer to the new name.
What’s not changing:
Old symbols: Existing symbols (eg. napi_create_reference) will remain the same. This ensures ABI stability, such that a previously compiled add-on will continue to load in newer Node versions.
Types, macros and defines: Names like napi_status, NAPI_MODULE, the Napi namespace (in node-addon-api) will remain the same. This ensures existing code can be recompiled with no changes.
The Node.js Mentorship Initiative is excited to announce a new opening. We are looking to add a new mentee to our initiative. We, therefore, invite developers who are passionate about the Node.js ecosystem and are willing to learn and contribute towards its growth and development to apply to this opportunity.
The Mentorship initiative prides itself in identifying specific needs of Working Groups and Initiatives within Node.js and posts applications for available opportunities.
Over the past year, we have helped the Examples Initiative and the N-API working group to recruit new mentees, which is in line with our objective of helping to bring more and more contributors into the Node.js ecosystem, and eventually the broader OpenJS ecosystem.
We’re looking for someone with a decent knowledge of GitHub, good technical and communication skills, as the responsibilities of a mentee will include routine repo maintenance, communication with other initiatives to gather feedback, and the design of technical challenges to be completed by applicants.
This is a great opportunity to make a meaningful impact on Node.js while learning from industry leaders and world-class software engineers. Please apply here by May 13th, 2021. We look forward to receiving your application.
Initially, Node.js v 16 will replace Node.js 15 as our ‘Current’ release line. As per the release schedule, Node.js 16 will be the ‘Current’ release for the next 6 months and then promoted to Long-term Support (LTS) in October 2021. Once promoted to long-term support the release will be designated the codename ‘Gallium’.
As a reminder — Node.js 12 will remain in long-term support until April 2022, and Node.js 14 will remain in long-term support until April 2023. Node.js 10 will go End-of-Life at the end of this month (April 2021). More details on our release plan/schedule can be found in the Node.js Release Working Group repository.
A new major release is a sum of the efforts of all of the project contributors and Node.js collaborators! Congrats to all who made it possible!
Read the full blog with all the details on the Node.js blog.
Node.js Certifications and Training Sale + New Preview of Testing Environment
Training and certifications are some of the most valuable investments we can make in ourselves, to both sharpen our skills, but also to show prospective employers, and the world, that you have what it takes as a developer. Now is a great time to invest in yourself, or in your engineering team. Starting March 29 through April 9, the OpenJS Foundation, in partnership with the Linux Foundation, will be discounting all Node.js Certification and Training.
Limited offer: check out the new preview testing environment Today, in partnership with the LF, we are rolling out a free Node.js Environment Preview beta exam, which focuses on our Node.js certifications, the OpenJS Node.js Application Developer (JSNAD) and OpenJS Node.js Services Developer (JSNSD).
One of the most frequent requests we receive is to preview what the certification exam experience is like before actually sitting for an exam. Whether you get tripped up from text anxiety or low bandwidth, running through this Node.js Environment Preview will make you more familiar with the look and feel of the certification exam experience. This way you will know what to expect so you can focus on your Node.js knowledge.
This Node.js Environment Preview beta is available for a limited time — we have 4,000 free coupons to give away. Try it out and see how you performed on this self-graded environment preview. And don’t pass up this big sale.
The OpenJS Node.js Application Developer certification is ideal for the Node.js developer with at least two years of experience working with Node.js. For more information and how to enroll: https://training.linuxfoundation.org/certification/jsnad/
The OpenJS Node.js Services Developer certification is for the Node.js developer with at least two years of experience creating RESTful servers and services with Node.js. For more information and how to enroll: https://training.linuxfoundation.org/certification/jsnsd/
Feel confident in taking your exams with the Node.js Training courses. These courses help prepare developers for the Node.js certification exams.
This course provides core skills for effectively harnessing a broad range of Node.js capabilities at depth, equipping you with rigorous skills and knowledge to build any kind of Node.js application or library. While by design the training content covers everything but HTTP and web frameworks, the crucial fundamentals presented prepares the student to work with web applications along with all types of Node.js applications.
This course provides a deep dive into Node core HTTP clients and servers, web servers, RESTful services and web security essentials. With a major focus on Node.js services and security, this content is an essential counterpart to the Node.js Application Development (LFW211) course, and will prepare you for the OpenJS Node.js Services Developer (JSNSD) exam.
If this sounds like something you’d like to know more about, check out more information at this link.
TLDR; We need your help to make sure the Next 10 years of Node.js are as successful as the first. We are launching a survey, you can take it here to help us do that. To get a bit more context on why this survey is important, read on….
Node.js had a very successful first 10 years of Node.js and the project is working to make the next 10 years even better. As part of that we’ve kicked off the Next-10 effort to document what we think is important for that to happen. You can follow the ongoing work of that team in this repo: https://github.com/nodejs/next-10.
Without a handy crystal ball, it turns out that it’s a lot harder than just diving in and discussing our favorite technologies to see what the keys to success are going to be. Are things like WebAssembly, Typescript, etc. important to the people who use Node.js? I guess we need to better understand/document who uses Node.js first…..
So far the team has spent most of its time laying the foundation on which we hope to base discussions around specific technologies.
We started by documenting our understanding of the project’s technical values as these will help us balance different aspects when necessary: https://github.com/nodejs/node/blob/master/doc/guides/technical-values.md. It’s not as simple as X overrides Y but instead highlight what key values need to be factored into decisions. For example, there was consensus that good developer experience has been a key part of the success of Node.js and that it’s important for future success that we maintain that.
Next the team documented the Node.js “Constituencies”. The people/groups who have a stake in the Node.js ecosystem. We captured these in CONSTITUENCIES.md are include:
We think we’ve got a good start, but at this point it only reflects the understanding of the small number of Next-10 team members contributing. At this point, we need your help to make sure we’ve got it right and/or update until we do. You can do that by:
For those wanting to start learning Node.js, the path has not always been clear. While there are many free resources and forums available to help, they require individual planning, research and organization which can make it difficult for some to learn these skills. That’s why The Linux Foundation and OpenJS Foundation have released a new, free, online training course, Introduction to Node.js. This course is designed for frontend or backend developers who would like to become more familiar with the fundamentals of Node.js and its most common use cases. Topics covered include how to rapidly build command line tools, mock RESTful JSON APIs and prototype real-time services. You will also discover and use various ecosystem and Node core libraries, and come away understanding common use cases for Node.js.
This blog was written by A.J. Roberts and the Node.js Mentorship Initiative team. This post was first published on the Node.js blog. Node.js is an impact project at the OpenJS Foundation.
The Node.js Mentorship Initiative is happy to announce our next opportunity. This one is open to developers with experience in C++. You will work hand-in-hand with the N-API working group members with the eventual goal of becoming a full-fledged member of the working group.
If you’re not familiar with the working group, we recommend checking out their recent blog post.
The N-API working group has the goal of making it easier to develop native addons for Node.js and other runtimes like Electron. They have already accomplished a lot of crucially important work for the Native Addons ecosystem. You can help them accomplish even more by improving test coverage, adding features to N-API, and creating examples for native plugin authors to follow.
The N-API working group will set aside time specifically for helping and guiding you, so it’s definitely worth applying through the Mentorship Initiative if you feel like this would benefit you. In order to do that, you should complete the application and its included challenge. The challenge is expected to take 2–4 hours to complete.
Please apply here by January 29th, 2021. We look forward to seeing your submissions.
Ryder’s low-code, screen scraping solution was an effective solution for a long time, yet, as their customers’ expectations evolved, they had an opportunity to upgrade.
To keep up with consumer demand, they implemented Profound Logic’s Node.js development products to create RyderView. Their new web-based solution helped transform usability for their customers and optimize internal business processes for an overall better experience.
Third-party freight carriers across North America rely on Ryder’s Last Mile legacy systems to successfully deliver packages. Constantly adding features the legacy system made for a a monolithic application that was no longer intuitive nor scalable.
The Ryder team, lead by Barnabus Muthu, IT & Application Architect, wanted to develop an intuitive web application that provided real-time access to critical information. Muthu wanted to balance the need for new development with his legacy programs’ extensive business logic.
Profound Logic’s Node.js development solutions were a great fit and allowed Muthu to expose his IBM i databases via API to push and pull data from external cloud systems in real-time. He was also able to drive efficiency on dev time by using npm packages. Using Node.js, Ryder was able to built a modern, web-based application that no longer relied on green screens, while leveraging his existing RPG business logic.
This new solution was named RyderView and it transformed usability for its customers, translating to faster onboarding and reduced training costs for Ryder.
For third-party users, it led to improved productivity as the entire time-consuming processes were made obsolete. Previously, Ryder’s third-party agents used paper-based templates to capture information while in the field. Now that Ryder’s new application used microservices to push and pull data from iDB2, end users were upgraded to a mobile application. These advancements benefited Ryder as well, allowing them to eliminate paperwork, printing costs, and the licensing of a document processing software.
Now is a great time to invest in yourself, or in your engineering team. Starting November 30 through December 8, the OpenJS Foundation, in partnership with the Linux Foundation, will be discounting all Node.js Certifications and Trainings. The OpenJS Certification and Training program serves to help developers in their professional development goals.
Certifications are excellent ways to validate your own development skills to yourself, employers, and the world.
OpenJS Node.js Application Developer (JSNAD) The OpenJS Node.js Application Developer certification is ideal for the Node.js developer with at least two years of experience working with Node.js. For more information and how to enroll: https://training.linuxfoundation.org/certification/jsnad/
OpenJS Node.js Services Developer (JSNSD) The OpenJS Node.js Services Developer certification is for the Node.js developer with at least two years of experience creating RESTful servers and services with Node.js. For more information and how to enroll: https://training.linuxfoundation.org/certification/jsnsd/
Feel confident in taking your exams with the Node.js Training courses. These courses help prepare developers for the Node.js certification exams.
Node.js Application Development (LFW211) This course provides core skills for effectively harnessing a broad range of Node.js capabilities at depth, equipping you with rigorous skills and knowledge to build any kind of Node.js application or library. While by design the training content covers everything but HTTP and web frameworks, the crucial fundamentals presented prepares the student to work with web applications along with all types of Node.js applications.
Node.js Services Development (LFW212) This course provides a deep dive into Node core HTTP clients and servers, web servers, RESTful services and web security essentials. With a major focus on Node.js services and security, this content is an essential counterpart to the Node.js Application Development (LFW211) course, and will prepare you for the OpenJS Node.js Services Developer (JSNSD) exam.
If you’d like to pursue Node.js Certifications and Trainings and this sounds like something you’d like to know more about, check out more information at this link.
N-API provides an ABI-stable API that can be used to develop native add-ons for Node.js, simplifying the task of building and supporting such add-ons across Node.js versions.
With downloads of node-addon-api surpassing 2.5 million per week, all LTS versions of Node.js supporting N-API version 3 or higher and node.js 15.x being released with support for N-API 7, it is a good time to take a look at the progress on simplifying native add-on development for Node.js.
When we started working on N-API back in 2016 (the original proposal is 12 Dec 2016) we knew it was going to be a long journey. There are many native packages in the ecosystem and we understood the transition would take quite some time.
The good news is that we have come a long way since the initial proposal. There has been a lot of work by the Node.js collaborators and the team focussed on N-API as well as package authors who have moved over. In that time, N-API has become the default recommendation for how to build native add-ons.
While the basic design has remained consistent (as planned), we’ve added incremental features in each new N-API version in order to address feedback from package authors as they adopted N-API and node-addon-api.
Having said that, let’s dive into some of the new features/functions that have been added over the last few years.
As people have been using N-API and node-addon-api we’ve been adding the key features that have been needed, including generally improving the add-on experience.
The changes fall into 3 main categories which are covered in the sections which follow.
Multi-Threaded and Asynchronous Programming
Performing computationally-intensive tasks on the main thread will block program execution, queuing events and callbacks in the event loop. As we gained experience with real-world use, in order to facilitate program integrity across multiple threads, both N-API and its wrapper node-addon-api were updated to provide several mechanisms to call into the Node.js thread from outside the main event loop, depending on use-case:
AsyncWorker: provides a mechanism to perform a one-shot action, and notify Node.js of its eventual completion or failure.
AsyncProgressWorker: similar to the above, adding the ability to provide progress updates for the asynchronous action.
Thread-safe functions: provides a mechanism to call into Node.js at any time from any number of threads.
Another recent Node.js development is the arrival of workers. These are full-fledged Node.js environments running in threads parallel to the Node.js main thread. This means that native add-ons can now be loaded and unloaded multiple times as the main process creates and destroys worker threads.
Since threads share the same memory space as the main process, multiple copies of a native add-on must now be able to co-exist in a single process. On the other hand, the library containing a native add-on is only loaded once per process. Thus, global data stored by a native add-on, which was so far stored in global variables, must no longer be stored in such a way, because global storage is not thread-safe.
Static data members of C++ classes are also stored in a thread-unsafe manner, so those must also be avoided. It’s also important to remember that the thread is not necessarily that which makes an add-on instance unique. Thus, thread-local storage of global variables should also be avoided.
In N-API version 6 we started providing a space for storing per-instance global data by introducing the concept of add-on instances, multiple of which can co-exist in a process, and by providing some tools for creating self-contained add-ons, such as
the NAPI_MODULE_INIT()macro, which will initialize an add-on in such a way that it can then be loaded multiple times during the life cycle of the Node.js process.
The node-addon-api Addon<T> class, which neatly combines the above tools to create a class whose instances represent instances of an add-on present in the various worker threads created by Node.js. Thus, add-on maintainers can store per-add-on-instance data as variables in an instance of the Addon<T> class and Node.js will create an instance of the Addon<T> class whenever it is needed on a new thread:
Additional helper methods
As package maintainers used N-API we discovered a few additional APIs that were commonly needed. These included:
Retrieving property names from objects
One of the other main areas where the N-API team worked to fill in gaps and make it easier for maintainers to consume N-API was the build workflow, including additions to CMake.js, node-pre-gyp and prebuild.
Historically, Node.js native addons have been built using node-gyp. For source code libraries that are already being built using CMake, the CMake.js build tool is an attractive alternative for building Node.js native add-ons. We have recently added an example of an add-on built using CMake.
Detailed information about using CMake.js with N-API add-ons can be found on the N-API Resource.
One of the realities of developing Node.js native add-ons is the fact that as part of installing the package using npm install the C or C++ code must be compiled and linked. This compilation step requires that a viable C/C++ toolchain be installed on the system doing the compilation. This can present a barrier to the adoption of native add-ons as the user of the add-on may not have the necessary tools installed. This can be addressed by creating prebuilt binaries that can be downloaded by the user of the native add-on.
A number of build tools can be used to create prebuilt binaries. node-pre-gyp builds binaries that are typically uploaded to AWS S3. prebuild is similar to node-pre-gyp but uploads the binaries to a GitHub release.
prebuildify is another option similar to the above that enables the native add-on developer to bundle the prebuilt binaries into the module uploaded to npm. The advantage of this approach is that the binaries are immediately available to the user when the package is downloaded. Although the downloaded npm package is larger in size, in practice the entire download process is faster for the user because secondary download requests to AWS S3 or a GitHub release are unnecessary.
Resources for getting started
One resource available to help get started is the node-addon-examples GitHub repository, containing samples of various Node.js native add-ons. The root of the repository contains folders for different functional aspects, from a simple Hello World add-on to a more complex multi-threaded add-on. Each example folder contains up to three subfolders: one for each Node.js add-on implementation (legacy NAN, N-API, and node-addon-api). To get started with the Hello World example using the node-addon-api implementation, simply run:
Another resource available is the The N-API Resource. This website contains information and additional in-depth walkthroughs regarding building Node.js add-ons and other advanced topics, such as:
tools needed to get started
migration guide from NAN
differences between build systems (node-gyp, cmake, …)
context-sensitivity and thread-safety
Closing out and call to action
The resulting C API is now a part of every Node.js distribution and a C++ convenience wrapper called node-addon-api is distributed as an external package through npm. N-API was launched with the promise to guarantee the API and the ABI compatibility across different major versions of Node.js and this has introduced a series of benefits:
It has removed the need to recompile modules when migrating to newer major versions of Node.js
Since N-API is a C API it is possible to implement native add-ons using languages other than C / C++ (such as Go or Rust).
When N-API has been released as an experimental API in Node.js v8.0.0 its adoption started to grow slowly, but many developers started to send feedback and contributions and this led us to add new features and to create new tools to better support all the native add-ons ecosystem.
Today N-API is widely used for the development of native add-ons. Some of the most used native add-ons have been ported to N-API:
We are constantly making progress on N-API and in general on the native add-ons ecosystem, but we always need more help. You could help us and the whole community to continue improving N-API in many ways:
Porting your own native module to use N-API
Porting a native module that your app depends on to N-API