WebTransport transport

[bhollis]

Is your feature request related to a problem? Please describe.

We'd like to make use of bidi and client streaming from web browsers. This is currently not supported by the fetch (browser) transport for connect-es.

Describe the solution you'd like

A new transport based on the WebTransport API. This is also on the roadmap for grpc-web so maybe there's some shared effort possible. WebTransport allows for full duplex streaming, though it isn't yet supported in Safari (they are supportive of it, so it should show up eventually).

This would be primarily useful for the browser, though I suspect server runtimes like NodeJS and Deno will eventually include it.

Describe alternatives you've considered

1. Implement a WebSockets transport, though that would require server changes.
2. Implement the WebTransport transport ourselves.

[perezd]

We're interested in seeing bidi streaming support for Connect RPC via WebTransport; we've just not gotten a chance to implement it yet! As you've pointed out, the lack of Safari support has historically made us de-prioritize this effort, but we agree this is needed.

Would you be interested in collaborating on developing this capability?

[bhollis]

Definitely, I've been meaning to get a chance to hack on a WebTransport gRPC implementation.

[perezd]

Great! I'd recommend we do some realtime chatting/meeting about this in our CNCF slack channel (#connectrpc), would you mind joining over there? https://communityinviter.com/apps/cloud-native/cncf

[krapie]

Just to confirm, ConnectRPC isn't working on this issue because Safari doesn't support WebTransport, correct?

[perezd]

That's correct. We believe that is the right path forward to support streaming, and that is a prerequisite we are waiting for.

[davidfiala]

FYI to OP: I've offered #1375 to unblock Chromium-based browsers with half-duplex client streaming. It has the caveat that bidi-streaming blocks server messages until the client's half is complete. Unsupported browsers continue to receive a thrown error. This is purely an incremental improvement until/as browser support improves.

[bhollis]

Thanks! Unfortunately this doesn't really help for our usecase which requires full duplex.

[jlewi]

Any update on expected timeline for WebTransport support? I think it would be a huge help for those building AI web apps like myself if the connect supported webtransport.

In my case, I'm building an AI agent based web application. Half duplex streaming in AI (using server side eventing) is the norm and pretty critical to masking the latency of really long generation times. As Assistants evolve I think full duplex streaming is going to be critical. You can look at the OpenAI Assistants API for examples. At a high level, your assistant is running a reasoning loop and streaming responses to the user. The responses include text but also tool calls (e.g. a shell command) that the user should invoke. After the user invokes the tool call you want to send the output back up to the agent so it can incorporate it into the reasoning loop.

Does it really make sense to hold the entire ecosystem back just because of Safari? Is the concern that the protocol is still evolving and may change significantly?

In my case, I'm building an internal web app and mandating chrome in order to get streaming isn't really a concern. It seems likely we will see AI push browser technology forward (e.g. a new set of browsers). I think it would be great if protos & connect could become the standard to build those applications.