Support Client Streaming for fetch API
Is your feature request related to a problem? Please describe. We cannot use client stream on web.
Describe the solution you'd like Support client stream requests with the fetch API by default.
Describe alternatives you've considered I can write use own transport function.
Additional context Streaming requests with the fetch API by Chrome Developers
Hey @oott123, thanks for raising the issue. So far, we have held off supporting client-streaming because it is not widely supported yet.
On MDN, the browser compatibility table shows a sad red X for "Send ReadableStream in request body" with Firefox and Safari, so you cannot rely the feature yet.
We'd love to push the boundary here, but we have to make sure that it works correctly on the supported browsers, and reliably raises a helpful error message for browsers that do not.
Actually, Firefox already supported this feature, at least here on my machine, and yes I completely agree that we should add tests to make sure that it works correctly.
Actually, Firefox already supported this feature, at least here on my machine
Could you share which version you are running? We did not see the feature detection recommended by the Chrome Developers Blog working with the developer edition.
@timostamm I'm so sorry, I have re-checked this on my Firefox (114.0.1) browser and it do does NOT work. Sorry for my mistake, I may confused between browsers.
If Client Streaming can't be supported yet, how does file uploading work with the connect protocol?
If you want a pure Connect solution, the best option for large files would probably be to chunk up the file on the client and then send individual unary requests to the backend and then reassembling the chunks there.
In addition, depending on the size of the file, you could potentially send it all in one request rather than having to chunk it.
@smaye81 so you propose to build a custom streaming solution? :worried:
Since client-streaming is not yet supported from browsers, those are probably your options. You could use regular HTTP and multipart form data, also. But if you wanted a pure Connect approach from a browser, then your options are limited unfortunately.
Some gRPC-Web implementations such as Improbable's gRPC-Web client facilitate client-streaming via websockets, but Connect does not support that at the moment.
This is sad but understandable. It would be nice if this workaround is somehow managed by Connect protocol. As a Dev, I need to plumb all together again, which I wanted to prevent by using Connect in the first place.
Yeah, that's fair. We're keeping an eye on support for sending ReadableStream and evaluating possible alternatives, so hopefully, we have an answer for this in the near future.