WASM Support on twilight-http

[ByteAlex]

Hey there!

I recently started working on writing a Cloudflare Worker library for Interactions using twilight-model and twilight-http, though twilight-http uses tokio, which is currently not supported by Cloudflare Workers.
Is there any chance to get a feature which does not compile tokio and makes it possible to compile to WASM?

Thank you & Best Regards
Alex

[HTGAzureX1212]

Hi Alex,

As far as I know, the twilight-http crate only supports the usage of the Tokio runtime for its asynchronous runtime (citation needed). There seem to be some work on bringing Tokio itself to WASM. but I am not entirely sure would it help, and neither am I familiar with Cloudflare Workers.

As from my experience, most HTTP operations are asynchronous which require some sort of an asynchronous runtime to run. There are two commonly-used asynchronous runtimes in the Rust ecosystem: async-std and tokio. Twilight, as far as I know, does not support async-std (citation needed); is async-std supported in Cloudflare Workers by any chance, or are asynchronous runtimes just not supported in them (as I said, I am not that familiar with Cloudflare Workers)?

Hope this helps.

Regards,
HTGAzureX1212. (HTG-YT)

Edit: cc @Erk-, who have worked on this before.

[ByteAlex]

Hi!

Thanks for your reply.

The rust async keyword is in fact supported and I understand that complex operations like rate-limiting do need a more complex async support through i.e. Tokio, but in case of CF Workers we do not carry any state between requests anyway, because every invocation of the webhook runs in its own runtime.

Thus I basically just want to use a "simple" wasm compatible version of twilight-http, which just exposes the routes in a simple programatically way without messing with custom request creation.

If I saw correctly twilight-http uses hyper underneath for normal requests. A wasm feature would probably just rely on a wasm-http crate, for example reqwest supports wasm.

After looking a bit more at the code, I feel this could be a bigger problem then initially anticipated, but it may still be an interesting feature to have.

[HTGAzureX1212]

Hi Alex,

Upon closer inspection, the features twilight-http use in tokio seem to support WASM. The issue lies in hyper indeed, because there is no support for WASM yet.

There's another solution: gate hyper related things behind a feature flag and expose the request and routing modules for users to directly translate them into their own Request types to use, making that possible to use reqwest as you mentioned.

Not really sure is that the best way, but upon discussion in the Discord that might worth a go.

Hope this helps.

Regards,
HTGAzureX1212. (HTG-YT)

[ByteAlex]

Hey,

thanks for coming back on that.

As long as the features from tokio do not rely on a tokio runtime, it should work, because Cloudflare Workers does not allow to create a tokio runtime within the worker.

Gate hyper behind a feature flag sounds good, but I'm not sure if it's worth adding the overhead for exposing request and routing right to the end user.
It may be easier to just implement a reqwest feature flag as an alternative http engine, which should be pretty easy, as reqwest uses hyper underneath (unless compiled for wasm) and it's from the same author.

But either way, if it's too much effort to implement those changes we can wait for the WASM PR on hyper to be merged.

I still have concerns with tokio, but that needs to be tested.

Best Regards
Alex

[Erk-]

Hello,

It may be easier to just implement a reqwest feature flag as an alternative http engine, which should be pretty easy, as reqwest uses hyper underneath (unless compiled for wasm) and it's from the same author.

This was the way I ran with when I tried this in the past, though got stuck on various things such as missing support in tokio and some types being a bit too different between them to make it clean. I might give it another try this weekend and see if I can get something working with either the hyper patch or by not using hyper.

==========
Valdemar

[ByteAlex]

Hey there!
Any update to this yet?

[Erk-]

I have not had time to look at it much yet, the hyper wasm cannot be used directly at least since it seems to cause other issues. So I will look into maybe abstracting the http client away though that is quite a bit more work

[banocean]

Cloudflare workers allow using wasm and wasi, to use apis from js it requires using wasm-bindgen that is used in wasm implementation of the reqwest crate, same approach is used in the worker crate provided by cloudflare.

https://github.com/seanmonstar/reqwest/blob/master/src/wasm/client.rs
https://blog.cloudflare.com/workers-rust-sdk/

There is no way to run a normal hyper client with wasm. Hyper is build on h1 and h2 that are http implementations. js build-in api's simply doesn't provide enough abilities to achieve same level of details to expose api with exact same data and methods.

What about WASI?
Currently support of network apis in WASI is very limited. There are two proposals wasi-sockets and wasi-http. Propably wasi-sockets should expose enough apis for tokio/net to support them.

https://github.com/WebAssembly/wasi-sockets
https://github.com/WebAssembly/wasi-http
tokio-rs/tokio#4827

WASI is supported by cloudflare workers and would not require any additional work here (if there will be proper apis in place to cover tokio/net).

https://blog.cloudflare.com/announcing-wasi-on-workers/