feature gate subscription-over-websocket under tide-integration

[extraymond]

Description of the feature

It would be nice to feature gate subscription-over-websocket under feature flag, mainly for platform that's not able to use spawning semantics more freely.

One current usage I would like to explore is to compile both tide and async-graphql as webassembly and deploy them to cloudflare worker. currently I was able to do so by manually mask the tide::tcp_listener/sse module and subscription module under async-graphql-tide-integration which both uses spawn with the executor.

The expected results is to deploy async-graphql and tide together to be used in cloudflare's edge instances(cloudflare-worker) where it can take web-sys::Request and return web_sys::Response. With tide's Server::respond method, it can not only be used as a headless request responder but also used in client-side application as a request proxy which might be useful sitting behind service-worker to rewrite request and sent it to the upstream servers.

Currently I think this can be achieved through two solutions:

1. simply masked subscription module if cfg(arch = "wasm")
2. create ["HttpTransport", "WebsocketTransport"] feature so people can decide if they want to manually pull the dependency
3. maybe moth?

I'm currently thinking sol.2 might be more general since some graphql client accepts subscription to be handled by sse instead of websocket. Since generally tide supports sse(not on wasm again...), maybe someone would like to support graphql-subscription over sse instead of websocket.

Code example (if possible)

#[wasm_bindgen]
pub async fn fetch(req: web_sys::Request) -> web_sys::Response {

    let app: tide::Server;
    // construct it with normal async-graphql-tide endpoint method.
    // currently not possible because pulling tide-websocket which is not possible in wasm. <--- this feature request

   // receive graphql-request and return graphql-response
   let resp = app.respond(req).await;

   // can be done manually trivially 
   let resp: web_sys::Response = resp.into();
  
  // we can now deploy server code to service-worker and lambda-edge or cloudflare-worker where server-side js runtime sits.
  resp
}

[sunli829]

If you just provide a GraphQL interface, I don't think you need to use tide. 😁

Maybe you can take a look at this:
https://dylananthony.com/posts/graphql-lambda-rust

[extraymond]

If you just provide a GraphQL interface, I don't think you need to use tide. grin

Maybe you can take a look at this:
https://dylananthony.com/posts/graphql-lambda-rust

Yeah I know, but it would be even awesome if I can handle non-graphql endpoints with tide as well haha.
I have some middleware doing authentication that I would like to use guarding endpoints as tide middleware so there's some usage besides async-graphql.

[sunli829]

I got it, let me think about what to do. 🙂

[sunli829]

Released in v2.10.0