connect-es icon indicating copy to clipboard operation
connect-es copied to clipboard

Support Client Streaming for fetch API

Open oott123 opened this issue 2 years ago • 14 comments

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

oott123 avatar Jun 06 '23 16:06 oott123

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.

timostamm avatar Jun 07 '23 14:06 timostamm

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.

oott123 avatar Jun 07 '23 16:06 oott123

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 avatar Jun 12 '23 20:06 timostamm

@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.

oott123 avatar Jun 13 '23 05:06 oott123

If Client Streaming can't be supported yet, how does file uploading work with the connect protocol?

StarpTech avatar Jul 03 '23 08:07 StarpTech

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 avatar Jul 05 '23 19:07 smaye81

@smaye81 so you propose to build a custom streaming solution? :worried:

StarpTech avatar Jul 05 '23 20:07 StarpTech

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.

smaye81 avatar Jul 05 '23 21:07 smaye81

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.

StarpTech avatar Jul 05 '23 22:07 StarpTech

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.

smaye81 avatar Jul 06 '23 13:07 smaye81