Open bartlomieju opened 4 months ago
For Brioche, I use serde_v8
for quite a few of the important ops in the runtime. The data structures are fairly big and often deeply-nested, so I don't think translating these structures to a regular list of primitive arguments would be feasible
I could just use JSON.stringify()
/ serde_json::from_str()
on either side, or I'm sure I could write some manual de/serialization for v8::Value
types, but is there some general guidance or pattern to avoid either of these options?
@bartlomieju
Removal of serde_v8 would entirely break a lot of paths from v8 types to rust types
It would entirely, completely break rustyscript
I would urge you guys to reconsider. It is very easy to misuse a lot of things, but that is not a reason to remove them entirely imho
Better documentation, warnings, or even feature-gating are all far better options
Discussed extensively with @nathanwhit @mmastrac and @dsherret.
We are planning to remove
serde_v8
completely. The reason is that in most cases usingserde_v8
is a big footgun in terms of performance.A stark example of perf footgun is
URLPattern
API that uses ops returning structures that are marked with#[serde]
. This API produces a lot of garbage, just because it returns objects that have 8-9 keys. On each op invocation the key is serialized and copied from Rust to V8. Then in JavaScript, this object is immediately destructured and GCed. Instead we could return an array of values, which would alleviate a lot of pressure on GC.This will need to happen over multiple PRs. The tentative plan of action is:
serde_v8::AnyValue
- this enum is used only for Deno KV APIs and can be easily replaced by usingv8::Value
directly.AnyValue
is gone, we can remove support for#[serde] arg
in#[op2]
. This is a big antipattern to pass structs as arguments - instead, the fields should be "unfurled" and passed as separate arguments to ops.JsBuffer
,StringOrBuffer
,BigInt
, etc. Most of these could use specialized attributes or implementToV8
andFromV8
traits directly.#[serde]
support in return value. Instead of returning structs we'd be returningv8::Array
orv8::Value
and it would be up to the caller to construct an object on JS side (if it's even needed). After checkingdeno
repo we don't have that many occurrences and should be fairly straightfoward to update.serde_v8
release saying that it's deprecated and unmaintained.serde_v8
crate altogether.In the meantime we can remove
serde_v8
benchmarks that will speed up CI indeno_core
.