Eventually switch node-osrm to Node.js's ABI stable N-API

[daniel-j-h]

Node.js's upcoming LTS is the first to provide a stable ABI for building native addons against. It's basically an ABI stable C interface around the existing Node.js API with backwards compatibility guarantees.

On top of the stable C ABI there is a header-only C++ wrapper which is more or less NAN with some minor differences (it's not completely a drop-in replacement).

I'm doing the same pattern for https://github.com/scanse/sweep-sdk and it's great for ABI compatibility. In the stable ABI you only expose symbols you can and have to guarantee stability for. Build your library once run it everywhere and link against new libraries without ABI issues.

It probably makes sense for us to switch to Node.js's stable N-API eventually: build the node-osrm addon once and have it running against all Node.js versions to come. The N-API is supported from the upcoming LTS on only - switching now already is neither possible nor desired (we have to support the current LTS).

As usual: needs to be benchmarked - will introduce a small ABI / API boundary.

References:

• https://nodejs.org/api/n-api.html
• https://github.com/nodejs/node-addon-api
• https://github.com/nodejs/abi-stable-node
• https://github.com/nodejs/abi-stable-node-addon-examples

cc @miccolis @kkaefer @springmeyer maybe interesting for you

[springmeyer]

Thanks for the great writeup @daniel-j-h - I agree that this is something we should ideally use. And to try it out soon such that we can influence the design if needed - it should not need to introduce unwanted performance penalties, but we'll want to make sure.

[daniel-j-h]

Looks like the C++ wrapper on top of the ABI stable N-API

https://github.com/nodejs/node-addon-api

also provides backwards compatibility: if we're building for Node < 8 we will just build against the the native C++ API which is not portable. But at least it allows us to switch node-osrm to node-addon-api for:

• node 4
• node 6
• node 8 and everything above

everything running via a single node-addon-api binding.

Then we can just drop node 4 and node 6 over time - so migration should be painless.