WebTransport transport
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
- Implement a WebSockets transport, though that would require server changes.
- Implement the WebTransport transport ourselves.
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?
Definitely, I've been meaning to get a chance to hack on a WebTransport gRPC implementation.
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
Just to confirm, ConnectRPC isn't working on this issue because Safari doesn't support WebTransport, correct?
That's correct. We believe that is the right path forward to support streaming, and that is a prerequisite we are waiting for.
FYI to OP: I've offered https://github.com/connectrpc/connect-es/pull/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.
Thanks! Unfortunately this doesn't really help for our usecase which requires full duplex.
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.
grpc-web has dropped plans for WebTransport: https://github.com/grpc/grpc-web/issues/24
Is this still planned here?
(side note WebTransport on Safari is possible under a feature flag as of Safari 18.4)
grpc-web has dropped plans for WebTransport
I wouldn't say it that way, more like "grpc-web will no longer be adding any new features and should be considered a legacy project."
There are lots of us who want to get this implemented, it's just a matter of someone having the time and priority to do so.
An update from our end:
We looked into the WebTransport APIs last year, but found that implementing streaming support for Connect isn't as straight-forward as it initially seemed. The API is minimal, and does not let users provide request headers - this means that request header, request messages, response headers, response messages, and end-of-stream response need to be encoded in payloads. This certainly isn't impossible to solve, but it does require a specification.
Another complication is the immature support for WebTransport outside of web browsers. Let's say you want to develop a frontend using streams over WebTransport: You'll likely want a local backend that supports streaming RPCs over WebTransport too. Ideally, a @connectrpc/connect-node server should be able to serve it, support in connect-go will likely be necessary, and support in vanguard-go and envoy's Connect-gRPC Bridge would be nice to have.
Because this is quite a bit more involved that we initially guessed, we put this feature on hold.
An update from our end:
We looked into the WebTransport APIs last year, but found that implementing streaming support for Connect isn't as straight-forward as it initially seemed. The API is minimal, and does not let users provide request headers - this means that request header, request messages, response headers, response messages, and end-of-stream response need to be encoded in payloads. This certainly isn't impossible to solve, but it does require a specification.
Another complication is the immature support for WebTransport outside of web browsers. Let's say you want to develop a frontend using streams over WebTransport: You'll likely want a local backend that supports streaming RPCs over WebTransport too. Ideally, a
@connectrpc/connect-nodeserver should be able to serve it, support in connect-go will likely be necessary, and support in vanguard-go and envoy's Connect-gRPC Bridge would be nice to have.Because this is quite a bit more involved that we initially guessed, we put this feature on hold.
Just wondering, where would submitting specification proposals for features like this be submitted?
See https://connectrpc.com/docs/governance/project-governance