Open janewang opened 2 months ago
There are many possible approaches on improving the XDR <-> TypeScript pipeline, each with their own trade-offs:
@stellar/stellar-xdr-json-web
requires an environment that can instantiate a WASM VM which may have non-trivial performance impacts. @willemneal is on point to do a secondary spike on whether or not it's feasible to use pointers from JS to WASM to avoid an encode/decode round-trip and improve the performance significantly.Does that cover things, guys? Feel free to edit my comment or add more thoughts below.
There may be existing solutions in 2024 that do XDR -> JSON/TS/JS better/faster/stronger than we do and @chadoh is on point to produce a research spike on those.
I asked @BlaineHeffron to help with this while I was busy with other things, and his discovery is "SDF is the only team building XDR libraries" and that, if we want something, we will need to be the ones to build it!
This spike is to evaluate the current architecture: xdrgen to js-xdr (where js-xdr produces an output which uses dts-xdr to output the d.ts typescript definition). Details in this doc.
Paths
One suggested path: In an ideal world, can go straight from xdrgen to typescript. (possibly rewrite js-xdr to ts-xdr?)
Another possible path: JSON => XDR. However, there is concern on performance (need to bundle) and also technical lift. Short term, we could potentially add a .toJSON() method to convert
Exploratory Ideas
We should timebox this spike to no more than 1 sprint.