Use `http` types directly instead of converting to and from them

[jyn514]

We'll still need to convert this in worker itself, because it needs to turn back into a wasm_bindgen::JsValue, but we don't need to add our own Response type, we can just use one from the ecosystem. Same for many of the other types (Request etc).

[nilslice]

This is sort of true - unfortunately the devil is in the details. We do actually need our own types, because the Cloudflare Workers runtime differs in subtle and major ways. The plan is to have our own base types that map 1:1 to the JS types exposed to the runtime, and then have conversion types for each that make sense. We can't just use the http::Request type as our baseline, because it would disallow a user from setting things like RequestInitCfProperties, or inspect request values on our cf object like colo.

I would be glad to know there is a more direct way to support these ecosystem types vs. conversion traits!

One magic way would be to decorate the event macro to use something like:

#[event(fetch, hyper)]
async pub fn main(req: hyper::Request, ...) -> Result<hyper::Response, E> { ... } 

In this approach, the code within the macro would rely on the conversion trait impls on our types to go from one to another. Definitely down-the-line thinking, and will certainly be impacted by end-user feedback.

[jyn514]

I would be glad to know there is a more direct way to support these ecosystem types vs. conversion traits!

I think we could make these available using https://docs.rs/http/0.2.4/http/struct.Extensions.html. So the syntax would look like

req.extensions_mut().get_mut::<RequestInitCfProperties>().unwrap().minify.javascript = true;

which is maybe a little verbose, but seems worth it to have ecosystem compatibility.

[jyn514]

We could make it less verbose by adding an extension trait:

use worker::RequestExt;
req.cf().minify.javascript = true;

which just calls extensions_mut().get_mut().unwrap() under the hood.

[michaelmerrill]

Any update on this? Axum 6.0 has an example of how to use their router in a wasm environment, however, the router.call() accepts an http::Request. An example of how to translate a worker request to a http request would be very helpful.

[zebp]

No real updates, there was a PR that worked on this but it wasn't merged due to some issues. I really like the idea of workers-rs reusing existing Rust http backend ecosystem but I'm not sure how well the JS and Rust sides of request/response will mesh. In JS the ownership of requests is very loose, I don't really know how things like Request::clone would work.

[JorgeAtPaladin]

+1 for being able to use web frameworks such as axum.