wasm32 support?

[sugyan]

If we try to use ATrium in an environment such as Cloudflare Workers (not sure if there is such a use case), it will be built with --target wasm32-....

However, the current atrium-api cannot be built with that target. Perhaps we encount the following error.

future created by async block is not `Send`.

This is because async_trait converts async functions to require dyn Future + Send, which seems to cause the build to fail on the wasm32 target.
It seems that we can write #[async_trait(?Send)] to work around this limitation.
https://docs.rs/async-trait/latest/async_trait/#non-threadsafe-futures

Many projects seem to use target_arch = "wasm32" to switch whether to add ?Send or not.
ATrium seems to be able to solve this problem in the same way.
https://github.com/search?q=%22%2C+async_trait%28%3FSend%29%29%5D%22+language%3ARust&type=code

By the way, if we can change MSRV to 1.75 in the future, we won't need to use async_trait, but we will probably use trait_variant::make then.
https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html#async-fn-in-public-traits

[str4d]

As far as I can tell, atrium-api and atrium-xrpc both build fine with --target wasm32-wasi:

$ cargo build -p atrium-api --target wasm32-wasi
[..]
    Finished dev [unoptimized + debuginfo] target(s) in [..]s
$ cargo build -p atrium-xrpc --target wasm32-wasi
   Compiling proc-macro2 v1.0.78
   Compiling serde v1.0.196
   Compiling quote v1.0.35
   Compiling syn v2.0.48
   Compiling serde_derive v1.0.196
   Compiling thiserror-impl v1.0.57
   Compiling async-trait v0.1.77
   Compiling thiserror v1.0.57
   Compiling serde_qs v0.12.0
   Compiling serde_json v1.0.113
   Compiling atrium-xrpc v0.9.0 (/path/to/atrium/atrium-xrpc)
    Finished dev [unoptimized + debuginfo] target(s) in 5.58s

What fails is atrium-xrpc-client, specifically the atrium_xrpc_client::reqwest module (failing with the error you describe above). But if you compile with --no-default-features (disabling the reqwest-native feature), it also compiles fine (which of course means there's no client enabled; fixing an individual client in the way you describe would be the next step).

[str4d]

I've added a CI job in #117 that pins the working wasm32-wasi build configuration (default features for atrium-api and atrium-xrpc, --no-default-features for atrium-xrpc-client).

[sugyan]

Thanks for the information.
As you pointed out, the main cause of the build failure seems to be only the xrpc-client part and not the atrium-api.

As far as I tried in my local environment, reqwest client seemed to work by modifying the async_trait part.
It seems that we will need to support only the reqwest client when using the wasm32 target.