N-API Support for node-nanomsg

[sampsongao]

The recently announced Node 8 has a new experimental feature called N-API which is aimed at reducing maintenance cost for node native addons. Checkout this blog for more details on its benefits.

Module node-nanomsg is one of the top 30 native modules by dependency count, and in order to help the Node.js community make the important transition to N-API, we are hoping you will be able to work with us in order to port node-nanomsg to support N-API. Your support and feedback is important in making this effort a success.

I am part of the N-API working group and and would like to talk to you about how you can can get started with N-API and what help we might be able to provide. I'm available to talk on the phone individually if you'd like. Alternatively, if you prefer, feel free to jump in our WG meeting which happens every Thursday at 1.30 Eastern / 10.30 Pacific US time, to discuss any issues.

Here’s a video of N-API in action

[nickdesaulniers]

Hi Sampson,
Thanks for letting us know about the N-API effort. Looks like you've already done a bit of porting work, which is cool (though I'm not sure which branch I should be looking at? I do think napi-wrapper-port is closer to NaN's interface, which is nice). Thank you for the meeting invite and demo video. I may take you up on that phone call. I'm surprised and happy to find this library is useful and helpful to others (I'm also a bit curious how those stats were collected?).

ABI stability is quite a tall order to achieve. The demo mentions chakracore-nightly, and it looks like a few people involved in the effort is employed by Microsoft. I'm really happy that Microsoft open sourced ChakraCore.

I think diversity of runtimes is a good thing, and I'd like to know more about:

• What are the future plans for chakracore + node?
• Where does N-API stand in relation to NaN? Is NaN deprecated?
• Why are folks at IBM working on this? Are they interested in moving Nodejs from v8?

I'm happy to discuss them in person over the phone, but I don't think that would be transparent to my fellow maintainers.

I realize there must be a chicken and the egg problem; it would be difficult to replace the VM for Node without native module support, but native modules won't switch to a non-existent runtime. It's smart to stage support for both runtimes in separate branches; once you reach critical mass, then it's possible to jump Node to have pluggable VMs.

Anyways, looks interesting, and I'll keep my eye on the project.

[reqshark]

Nice questions @nickdesaulniers! I have a couple too :)

nodejs/nan is an active project whose header#include <nan.h> supports older versions of node, i.e., it's a consistent way to invoke past v8 function signature flavors embedded across versions.

@sampsongao, my questions:

• What versions of node does N-API support?
• Is there a N-API module with a header to include for older node/v8 version support?

[sampsongao]

Sorry for the confusing branch. So the most up todate nanomsg port is under napi and node-addon-api. You are welcome to download the code and have a look.

For more details on node-ChakraCore and IBM involvement, you can ask Arunesh and Michael at our weekly meeting. Comparing to NaN, Napi is aiming to achieve ABI stability versus source stability so you can compile your code once and have the binding work across node version. Napi is going to replace Nan in the future (at least that is what we are trying to do).

Answering @reqshark 's question: Currently Napi support node v8.x and we plan to backport to node 6.x. For node 4.x, you can get old API through our node-addon-api module but it would not be ABI stable.

[mhdawson]

I'll comment on the IBM involvement. We've heard from module maintainers that there is pain in having to recompile and possibly make code changes for new versions of Node and are working to help lesson that problem as part of our involvement in the community.

We are also interested in ensuring Node.js can be used in different environments (ranging from small devices to larger servers) and having the flexibility to use different Javascript engines can support that. However, we don't have any specific plans or goals to move away from v8.