grpc-web
grpc-web copied to clipboard
grpc
Client Streaming
is Client Streaming not yet available to use? grpc-web_out doesn't generate client-side-streaming methods
Hi yeah i think you're right that only server-streaming is supported at this moment.. :)
Shouldn't this have been done by now according to the 2 year old roadmap? https://github.com/grpc/grpc-web/blob/master/doc/streaming-roadmap.md
We did a lengthy Chrome origin-trail from Q2-4/21 to test if streaming POST would work over HTTP/1.1, using Google's end-user facing traffic (gmail etc). Unfortunately the results are inconclusive. The Web API implementers are currently proposing to limit Fetch/streamed-upload to only HTTP/2. This will not work for grpc-web. Specifically, any non https origin defaults to HTTP/1.
Our plan is to support web-transport, which requires a fallback story for production deployment.
Will update the roadmap doc accordingly. Thanks for the notes!
I've been following the conversations on fetch streaming upload and it seems that, while the door is not completely closed to HTTP/1 support, HTTP/2 is all we'll have for a while. I'm adding my +1 to the web transport approach.
We have a data/analytics platform speaking gRPC to client apps, client streaming uploads would be really useful for us and avoid a lot of work-arounds.
I think that adding the support for client-side streaming sooner in some form would be a big help for many people wanting to adopt grpc for all of their applications.
There definitely should be more upvotes for this issue.
Totally agree. We had to resort to using grpc gateway to get client streaming and it's very roundabout
@wenbozhu The document has not been updated, is there a way you can put a brief update in here?
The last reference to the update that I can find is #301.
Hi :) Thanks for the interest here! I'll aim to work on a roadmap update soon. Will hopefully cover this topic. Thanks!
UPDATE: ETA Early January
@sampajano Thanks for the update, I think there is a lot if interest for grpc-web but this is the one thing that is blocking everything.
@Cliftonz Thank you sharing your view. Will definitely take that into consideration. Thanks! :)
An update to the roadmap is provided in https://github.com/grpc/grpc-web/pull/1326. Thanks all for the patience and support! 😃
I'm confused about the choice to go with WebTransport and not fetch/streams API. It seems like the argument is, because only some clients support writable streams with the fetch API today, we don't want to be in a situation where some clients do support it and others don't, so instead we're going with an approach that no clients support (because the spec isn't even final yet). That logic doesn't make sense to me. At some point the WebTransport spec will become final, and then it will be in the same state as fetch with writable streams, some clients will support it, and others won't.
RE: fetch/streams, it doesn't support full-duplex bidi, and client-streaming is disabled with http/1 (and only supported by Chrome). The complexity introduced to support fetch/streams for client-streaming only outweighs the benefit. Note grpc-web already supports server-streaming via fetch/streams.
WebTransport plans to support different fallbacks (via UA) over different HTTP protocols and the API supports full duplex bidi streaming. When QUIC and datagrams are enabled, the assumption is that WebTransport will see latency improvements for certain traffic types.