Proposed switch from neon to node-bindgen

[mycognosist]

Background

While scanning through the latest release of This Week in Rust on Saturday, I noticed this blog post: Sending tuples from Node to Rust and back. That introduced me to an alternative crate for generating bindings for Node: node-bindgen.

Yesterday I converted our batch verification & validation code to use node-bindgen and I have to say I like it a lot. It provides neat type conversion for JS values and stays out of my way so I can write idiomatic Rust code. I'm presenting some pro's and con's of the two approaches here so we can reach a decision together. I'll say up-front that I've in favour of node-bindgen.

Code Samples

A quick comparison of the verification function signatures, argument parsing and module exporting behaviour:

Neon (what we're currently using)

fn verify_message_array(mut cx: FunctionContext) -> JsResult<JsBoolean> {
    let js_msgs: Handle<JsArray> = cx.argument(0)?;
    let msg_array: Vec<Handle<JsValue>> = js_msgs.to_vec(&mut cx)?;

    // code code code

    Ok(cx.boolean(true))
}

// export our function for use in javascript
register_module!(mut cx, {
    cx.export_function("verifySignatures", verify_message_array)?;
}

node-bindgen

The secret sauce here is the #[node_bindgen] attribute (seen above the function signature definition) which automatically generates conversion code for Node and Rust to pass values back and forth.

Note: there's a slight difference here because this function is actually expecting an array of stringified values.

#[node_bindgen(name = "verifySignatures")]
fn verify_messages(array: Vec<String>) -> Result<bool, NjError> {
    // values are immediately available as `array`

    // code code code

    Ok(true)
}

// function is automatically exported ... no extra code required

neon

Pros:

• CLI package creation support
• Large user base (greater familiarity among devs?)
• Also seems actively maintained

Cons:

• Complicated interface
• Multi-step type conversion

node-bindgen

Pros:

• Actively maintained
• Clean, idiomatic interface (easier to write, easier to maintain)
• Allows introduction of novel type conversions (custom implementations)

Cons:

• Doesn't currently support publishing NPM modules with bundled binaries (Support for publishing NPM modules with binary targets infinyon/node-bindgen#131)

Conclusion

Without meaning to be rude, neon feels to me like it was written by JS devs while node-bindgen feels like it was written by Rust devs. Maybe that's an unkind thing to say but with neon I feel like I'm constantly working against the API.

In terms of performance, I have not yet seen a difference, so the key advantage of the switch here is maintainability of our code and improved developer experience. If I showed the node-bindgen validation code to another Rust dev they'd understand it instantly and could get to work implementing new features or making changes (no need to learn the esoterica of neon).

[staltz]

Yes, sounds great. I'm totally in favor of choosing something according to your intuition, and now the only thing I'm thinking is that I regret calling all these packages -neon because it couples the idea with Neon specifically. I think we could call it -jsrs (or -rsjs?) to make it more generic and also to open up the space for interchanging the rs-to-js library (be it node-bindgen or neon or something else) in the future.

[mycognosist]

Agreed that the generic naming approach is the way to go. -rsjs seems like a nice fit to me (describes the rs-to-js nature of the library). So then this would be ssb-validate2-rsjs :)

Should I get a PR together to enact the switch to node-bindgen?

[staltz]

Yes and yes! :)

I also feel like renaming ssb-neon

[mycognosist]

Great! I'll start right away :)

Somehow I didn't know about ssb-neon ssb-rsjs. That list of modules is very handy.

[staltz]

Another thing I'd like to prototype before doubling down on node-bindgen is compiling to Android and iOS. It was a headache to extend Neon to mobile and in the process I also built supporting libraries such as neon-load-or-build. I expect that moving to node-bindgen would give similar headaches.

I don't doubt it's possible, theoretically node-bindgen should work on Android and iOS with nodejs-mobile, we just need to try it out and fix issues until it works.

[mycognosist]

Leaving this here for future reference: infinyon/node-bindgen#114

[staltz]

Since you're developing on an rpi4, it's already correctly compiling for aarch64, right?

[mycognosist]

That's correct. I've been using my default toolchain for compilation (without any issues):

stable-aarch64-unknown-linux-gnu

[mycognosist]

Housekeeping

I'm closing this issue. Spoiler-alert: we ended up switching to node-bindgen (#8).