feat(neon): Serde implementation optimized with JSON #953

kjvalencik · 2023-01-06T21:24:30Z

Based on #701, but with the following changes:

Defers to JSON.stringify, JSON.parse and serde_json on non-primitive values
Adds cx.deserialize_args for getting a tuple from arguments

Questions

Are the lossy as casts acceptable or should we bring in a crate to more accurately capture failures?
Single element tuples are awkward in Rust (let (n,) = (u64,);). Should we include a deserialize_arg for unary methods to simplify things?
~~Is the very targeted FromArg acceptable in the near term or should we try to make a more generic TryFromJs?~~ Defer for the future. FromArg may be implemented in the future in terms of the other trait.
Users should not use FromArg or FromArgs. They are currently private, but that also hides the docs and make it unclear what types implement them. Should we make them available like Arguments? Should we make them public with the docsrs flag only? Expose them just like Arguments with the methods hidden.
Is there a way we can deserialize directly to T without a special method (deserialize_arg) and without conflicting with T: DeserializeOwned? Maybe with some wrapper type? let Arg(name): Arg<String> = cx.deserialize_args()? The type system is actually telling us [correctly] that the API is ambiguous. What if the function does take a single argument and that argument is a tuple?

*For future consideration
Now that GAT exist, what might it look like to be able to export function that automatically deserialize arguments and serialize return values?

cx.export_function("greet", |mut cx, (name,): (String,)| Ok(format!("Hello, {name}!")));

dherman · 2023-01-11T17:42:03Z

crates/neon/src/context/mod.rs

+    ) -> [Handle<'b, JsValue>; N] {
+        use std::ptr;
+
+        let mut argv = [JsValue::new_internal(ptr::null_mut()); N];


I think it's worth adding a comment here that Node-API fills slots with undefined if the number of actual arguments is smaller than the length of argv.

I should probably also document that the safety here depends on Handle<JsValue> being a transparent wrapper for a pointer.

Either that or accept that argv_exact is a leaky abstraction, mark it unsafe and return the raw pointers directly. There's an opportunity to individually wrap them with JsValue::new_internal when deserializing.

dherman

This looks great. I made a few suggestions for clarity, but you can make your own call and then I don't think I need to re-review unless you want.

dherman · 2023-01-12T05:43:11Z

crates/neon/src/serde/de.rs

+
+    match T::deserialize(unsafe { Deserializer::new(env, v) }) {
+        Err(Error::FallbackJson) => {}
+        res => return res,


Even though return can be used as an expression, stylistically I find it less distracting (easier to understand we're not doing anything fancy) to just use it like a statement:

res => { return res; }

Especially since here the whole match is just being used as a statement.

dherman · 2023-01-13T19:25:37Z

crates/neon/src/serde/de.rs

+    }
+}
+
+#[derive(Debug, Copy, Clone)]


This could use a purpose statement comment.

dherman · 2023-01-13T20:01:46Z

crates/neon/src/serde/de.rs

+        visitor.visit_string(unsafe { sys::get_value_string(self.env, self.value)? })
+    }
+
+    fn deserialize_bytes<V>(self, visitor: V) -> Result<V::Value, Self::Error>


I know it's more work but I think it would really help make the code understandable if each method like this has a comment explaining the mapping from the Serde IR type to the Rust type we've chosen (e.g. bytes -> ByteBuf). Maybe even showing an example like:

let data: ByteBuf = cx.deserialize_arg()?;

and

example(new ArrayBuffer(128))

dherman · 2023-01-13T20:07:47Z

crates/neon/src/serde/de.rs

+    types::{JsString, Value},
+};
+
+pub(super) fn deserialize<'cx, T, V, C>(cx: &mut C, value: Handle<V>) -> Result<T, Error>


So the heart of the deserialization algorithm is:

DESERIALIZE(v: JavaScript value) 1. If v is a primitive type, use Deserializer 2. If v is a compound type, call JSON.stringify(v) and use serde_json

dherman · 2023-01-13T20:08:50Z

crates/neon/src/serde/de.rs

+    Ok(serde_json::from_str(&s)?)
+}
+
+struct Deserializer {


Maybe we should call this PrimitiveDeserializer or NonRecursiveSerializer or BaseCaseSerializer or something like that, to make it more obvious what it's for.

FlatDeserializer? SimpleDeserializer?

so many possible colors for the bike shed

dherman · 2023-01-13T20:22:59Z

crates/neon/src/serde/mod.rs

+        static PARSE: LocalKey<Root<JsFunction>> = LocalKey::new();
+
+        PARSE
+            .get_or_try_init(cx, |cx| Ok(parse(cx)?.root(cx)))


Aside: It ever so slightly bugs me that we read JSON.parse lazily, which means if someone ever mutates global.JSON the program behavior is unpredictable. But I don't think we have any module loading lifecycle hooks that would allow decentralized code to register the creation and initialization of LocalKey values at module load time. Maybe an interesting idea for a future feature of LocalKey where you could write this code like this:

#[cfg(feature = "napi-6")] { static PARSE: LocalKey<Root<JsFunction>> = LocalKey::init_on_load(cx, |cx| Ok(parse(cx)?.root(cx)); Ok(PARSE.get().unwrap().to_inner(cx)) }

dherman · 2023-01-13T20:26:04Z

crates/neon/src/serde/ser.rs

+const MAX_SAFE_INTEGER: u64 = 9_007_199_254_740_991;
+const MIN_SAFE_INTEGER: i64 = -9_007_199_254_740_991;
+
+pub(super) struct Serializer {


Again, maybe a name that indicates this is the non-recursive serializer only?

dherman · 2023-01-13T20:29:26Z

crates/neon/src/serde/mod.rs

+    de::deserialize(cx, v).or_else(|err| cx.throw_error(err.to_string()))
+}
+
+/// Attempts to write Rust data into a JavaScript value using serde


So the basic algorithm here is:

SERIALIZE(x: Rust value) 1. If Serializer can serialize it to a base case JS value, use that 2. Otherwise use serde_json to create a string and call JSON.parse() on that

antonok-edm · 2023-08-09T02:08:01Z

@dherman @kjvalencik is there anything blocking here that I can help with? I've been suddenly running into a really weird issue that seems related to neon_serde; I could spend my time and effort debugging and working around that issue but I'd prefer to invest it towards something more useful here if possible.

kjvalencik · 2023-08-11T13:16:47Z

@antonok-edm that does look like a really strange bug! I may look into it if I get a chance.

As for this PR, I'm going to close it. I've been deliberating over this for a long time and decided that quietly switching to JSON in some circumstances is not the right approach. As demonstrated in your PR, it's already pretty easy for users to use JSON if that's their preference.

I'm going to open a new PR that is direct transcoding (closer to neon-serde) and document the caveats that it may be slower than JSON. Then if optimizations are made available to Node-API (currently, object related ones are private V8 APIs that only built-in JSON can leverage), we can make it faster without changing behavior.

There may still be some benefits of building JSON in, since it's such a common pattern. Do you have any thoughts here? Perhaps something like:

let (Something, Other, String) = cx.args_from_json()?;

antonok-edm · 2023-08-17T19:34:03Z

There may still be some benefits of building JSON in, since it's such a common pattern. Do you have any thoughts here? Perhaps something like:
let (Something, Other, String) = cx.args_from_json()?;

It doesn't seem like that'd support overloaded signatures (which could be fine, I guess). I think having an equivalent of what I wrote in the json_ffi mod here would be great though.

kjvalencik · 2023-08-17T20:35:42Z

We discussed this in our last meeting and the plan is to use a newtype approach similar to axum extractors. Something like:

let (a_string, a_number, Json(other_json)): (String, f64, Json<MyStruct>) = cx.args()?;

You could also have extractors that cover overloaded signatures cases like Either<String, f64>.

This covers the case where the value is already serialized JSON, but I see in your example it's calling JSON.stringify first. We could have something that did that, although I'm not sure what to call it (ViaJson?).

My plan is to first implement this and then bring back serde as an extractor type (and without the hacky fallback to JSON).

kjvalencik force-pushed the kv/json-serde branch from 645193a to 814213a Compare January 6, 2023 21:30

feat(neon): Serde implementation optimized with JSON

73d7da5

kjvalencik force-pushed the kv/json-serde branch from 814213a to 73d7da5 Compare January 6, 2023 21:49

kjvalencik added 5 commits January 6, 2023 17:45

Benchmarks

0df9ffc

Deserialize directly to Root

886dc9a

Lint fixes

e10da52

Remove pprof on windows

151bf3c

Update docs

974d287

kjvalencik marked this pull request as ready for review January 9, 2023 18:45

kjvalencik added 2 commits January 9, 2023 18:21

Docs

a2ffcf2

Update benchmark readme

92ac7d0

dherman reviewed Jan 11, 2023

View reviewed changes

Consistent handling of numbers

124b638

kjvalencik mentioned this pull request Jan 12, 2023

Expose a faster way to create objects with properties for Node-API nodejs/node#45905

Open

dherman approved these changes Jan 23, 2023

View reviewed changes

antonok-edm mentioned this pull request Jun 13, 2023

Bump neon from 0.9.1 to 0.10.1 in /js brave/adblock-rust#279

Closed

kjvalencik closed this Aug 11, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(neon): Serde implementation optimized with JSON #953

feat(neon): Serde implementation optimized with JSON #953

kjvalencik commented Jan 6, 2023 •

edited

Loading

dherman Jan 11, 2023

kjvalencik Jan 11, 2023 •

edited

Loading

dherman left a comment

dherman Jan 12, 2023

dherman Jan 13, 2023

dherman Jan 13, 2023

dherman Jan 13, 2023

dherman Jan 13, 2023

dherman Jan 13, 2023

dherman Jan 13, 2023

dherman Jan 13, 2023

dherman Jan 13, 2023

dherman Jan 13, 2023

antonok-edm commented Aug 9, 2023

kjvalencik commented Aug 11, 2023

antonok-edm commented Aug 17, 2023

kjvalencik commented Aug 17, 2023 •

edited

Loading

feat(neon): Serde implementation optimized with JSON #953

feat(neon): Serde implementation optimized with JSON #953

Conversation

kjvalencik commented Jan 6, 2023 • edited Loading

Choose a reason for hiding this comment

kjvalencik Jan 11, 2023 • edited Loading

Choose a reason for hiding this comment

dherman left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

antonok-edm commented Aug 9, 2023

kjvalencik commented Aug 11, 2023

antonok-edm commented Aug 17, 2023

kjvalencik commented Aug 17, 2023 • edited Loading

kjvalencik commented Jan 6, 2023 •

edited

Loading

kjvalencik Jan 11, 2023 •

edited

Loading

kjvalencik commented Aug 17, 2023 •

edited

Loading