Wasm support

[Dreaming-Codes]

It would be nice for this to support wasm since Axum already does

[andogq]

This seems like a reasonable idea. After a quick glance at jsonrpsee (which Qubit heavily relies on), it doesn't seem like they support WASM for the server, as they heavily rely on Tokio primitives.

How would you like to use Qubit with WASM? Are you intending it to act as a bridge between a Rust WASM library and a web app in the same browser? Or is it to help deploy servers to WASM platforms? Or is there something else?

[Dreaming-Codes]

I'm deploying to cloudflare workers which already supports Axum

[andogq]

Unfortunately it does seem that there'd be a good deal of work in order for us to make WASM possible. The possible options I see are:

1. Contribute to jsonrpsee to add WASM support for the server (it seems they heavily rely on Tokio, so this would likely be a massive/unrealistic change).
2. Swap to another JSON RPC implementation (nothing necessarily preventing this, however I'm not aware of any other viable options).
3. Creating a new JSON-RPC implementation that can support WASM
   • Hyper Service for compatibility with existing HTTP ecosystem
   • Handles upgrades into WebSocket implementation (it may be difficult to find a WASM-compatible provider for similar Tokio/scheduling reasons)
4. Add support in Qubit for multiple JSON-RPC implementations:
   • Full featured (incl. WebSocket/Streams): Non-WASM, full async runtime
   • Light weight (only query/mutation): Supports WASM, assumes 1 request/task per instance

Obviously none of these are simple. I would be very interested to see how this could be implemented however, so any ideas would be appreciated!

[Dreaming-Codes]

1. Contribute to jsonrpsee to add WASM support for the server (it seems they heavily rely on Tokio, so this would likely be a massive/unrealistic change).

Not sure on which features they rely on but some parts of tokio are supported in wasm.

Add support in Qubit for multiple JSON-RPC implementations:

• Full featured (incl. WebSocket/Streams): Non-WASM, full async runtime
• Light weight (only query/mutation): Supports WASM, assumes 1 request/task per instance

Websockets are supported in the cloudflare workers environment

[andogq]

Ah well that looks promising for WASM support. Have you tried compiling a Qubit project for WASM? If you can show what compilation errors occur, I'll be able to start working through them.

[Dreaming-Codes]

error: This wasm target is unsupported by mio. If using Tokio, disable the net feature.
  --> /home/dreamingcodes/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/mio-1.0.4/src/lib.rs:44:1
   |
44 | compile_error!("This wasm target is unsupported by mio. If using Tokio, disable the net feature.");
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

tokio net feature is not supported in wasm environments. I'm unsure if jsonrpsee utilizes this. Does jsonrpsee manage its own server, or does it delegate that to tower?

The getrandom WebAssembly support isn't working because my dependency override is for getrandom 0.3, but jsonrpsee is still using rand 0.8, which depends on getrandom 0.2. rand should be updated.

[andogq]

This is super helpful, thanks! :D

---

tokio net feature is not supported in wasm environments. I'm unsure if jsonrpsee utilizes this.

From a quick poke around, it seems that jsonrpsee has the ability to function as both a standalone server (running directly on-top of tokio::net primitives), or as a TowerService (what Qubit needs in order to pass the service to axum/other server).

Does jsonrpsee manage its own server, or does it delegate that to tower?

It seems the answer is: both.

I feel this two options (tokio and tower) could be feature-gated as default features, to preserve backwards compatibility whilst allowing users to turn off one or the other as required.

---

Edit: It seems that jsonrpsee is already using rand 0.9 . It seems in your example you're using an older version of Qubit 0.6, when the latest version (0.10) has a newer version of jsonrpsee.

Previous comment that's now irrelevant:

Bumping rand to 0.9 also doesn't seem like it'd cause problems at first glance. The documented override for use of getrandom in WASM is unfortunate, but I'm assuming this is a common problem for any crates in the ecosystem that rely on rand somewhere, so we'd just want to surface this documentation similarly to how rand does in their README.md.

---

I'm currently in the process of refactoring some big pieces of Qubit (for better tests and easier maintainability, nothing that would impact this work), which means I don't have the time at the moment to look at making these changes upstream. However, if you (or anyone else reading this) is interested in attempting it, I'd be more than happy to test and review what I can!