How should Ğ1 lib expose v2 features?

Clients Ğ1 lib
1

In a recent discussion we suggested multiple options for Ğ1 lib to expose both v1 and v2 features:

  • have two git branches “v1” and “v2”
  • use a different namespace
  • use shared namespace and hide the transition under the hood so that apps developed on v1 still work on v2

Also, Ğ1 lib will expose polkadotjs API as well as duniter-specific wrapped versions. How could the user load only the parts he needs to keep dependency as light as possible?

@1000i100 can you explain your point of view?

2 Likes
2

I don’t have a frozen answer to this, except for the dependency as light as possible part.
For that part, i try to build the lib in specialized sub-part and an all.mjs with all parts.

If you only need a part, you can only include a module.

If you want even less, the tree-shaking can remove unused stuff at build.

My problem with polkadotjs api is it’s mostly a wrapper for a rust wasm blob to run in js env, and this will kill any attemp of tree-shaking, or “as light as possible” lib. But the dev time to do the same in pure js/ts don’t look like a good way to spend time.
I’m also with performance question here : rust and wasm are optimised, but for cpu computation. If browser or node expose native crypto api using hardware specialized ship for computation, js using native crypto api will be much faster than rust/wasm with software cpu computation, it was the result of my last test in gsper between rust/wasm and js version (but it was with dunitrust and not polkadot wasm binaries).

In my dream, a shared namespace with a smooth transition would be perfect, but there will be some breaking changes.

I will probably do v3.x.x with duniter V1 as default behavior, and v2s available with options, and v4+ with duniter V2s as default behavior and v1 behavior with options…

But i’m not sure it will be best.

What i’ve done for server use and browser use is a common src with a specific build process and 2 folder in the distributed npm build.

Perhaps i will do the same : a common source with only specific stuff in separated folder, and at build, a folder for each use-case (v1-node, v1-browser, v2-node, v2-browser)

1 Like
3

Maybe you can make several WASM builds with different feature sets, and pick the minimal one corresponding to the wanted features when building your JS lib? But this is not convenient…

1 Like
4

I think we should not try to optimize what we chose not to develop ourselves and pick from the substrate ecosystem. If the choice is:

  • use v2 features → have wasm binary
  • do not use v2 features → do not have wasm binary

this is enough customization in my opinion. For the performance part, I think we can trust the substrate ecosystem to develop what’s needed for satisfying performances in most cases. If we need to develop something custom for a specific use case, we can do it, but we should not try to think it before this specific use case emerges.

@poka needs a POC of Ğ1lib v3 with v2s options to try integrate to Ǧecko web. I think this will help make future choices.

2 Likes
5

I’m not sure. They generally have very expensive computers and their company pays performant servers for CI or even remote compilation. They use bloated libraries for web and duplicate dependencies in Rust. They just don’t need to care about performance for everything else than block execution time.

One thing to check is whether the WASM uses native features (e.g. with the crate js-sys) or not (e.g. reqwest).

4 Likes