Open ByteAlex opened 1 year ago
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.
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.
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)
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
Hello,
It may be easier to just implement a
reqwest
feature flag as an alternative http engine, which should be pretty easy, asreqwest
useshyper
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
Hey there! Any update to this yet?
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
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 https://github.com/tokio-rs/tokio/issues/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).
Hey there!
I recently started working on writing a Cloudflare Worker library for Interactions using
twilight-model
andtwilight-http
, thoughtwilight-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