Bidi streaming use cases for grpc-web

[wenbozhu]

Options, use cases to enable bidi streaming support with grpc-web

[wenbozhu]

Re: community help, I think we'd be happy to review any spec proposals to support Web APIs such as websockets, and to help convince the Envoy community to accept a module to proxy bidi Web traffic to grpc services. However, we will not be able to support them as part of the grpc-web JS client, i.e. if no Google service will be using such a solution.

Re: timelines, the Chrome origin trials are happening in Q3. Maybe we will have something by Q4.

Re: webrtc data channels, I am not familiar with the use of webrtc for client-server communication, or if the JS API is available for regular web apps. Do you have any references on the use of webrtc datachannel for bidi client-server communication?

Thanks!

[blockspacer]

@wenbozhu

nice blog post about webrtc for client-server communication http://blog.brkho.com/2017/03/15/dive-into-client-server-web-games-webrtc/

code based on blog post from blog.brkho.com, but with updated C++ client version + boost.beast (websockets) for connection establishing https://github.com/lineCode/webrtc-datachannels/tree/develop/src/net/wrtc

conan package with docker container, may be used for webrtc builds (tested on ubuntu 18.04), patched for openssl support (instead of boringssl) https://github.com/blockspacer/conan-webrtc

[jsmouret]

I did a simple proof of concept at https://github.com/jsmouret/grpc-over-webrtc More documentation to come but it is a start :)

[wenbozhu]

Thanks for the information on webrtc.

@jsmouret feel free to file a separate issue on webrtc, e.g. maybe we could build something under https://github.com/grpc-ecosystem.

[wenbozhu]

We have post a road-map doc on our 2020 plan to improve the streaming support in grpc-web. Feel free to post any questions here or file a separate issue to discuss.

@ydesgagn for websockets, you may want to contribute something under https://github.com/grpc-ecosystem first. I am happy to review any spec on grpc/websockets.

[kshcherban]

Use cases:

• stream request (audio, video, text) from client in browser (javascript) and receive back results (audio, video, text) from server (grpc-go), it can be any type of video, voice chat, speech to text or text to speech, face recognition, image detection, etc.

[chwzr]

the roadmap looks very good! For my understanding: we are waiting for https://www.chromestatus.com/feature/5274139738767360 this to be available in major browser, to see the bidi-streaming magic happening here?

I really like the idea of not using any websockets in the future, just pure grpc / http. Please let us know if there are any updates on this :)

[chris-kruining]

upload streaming has landed in chrome 95. (https://web.dev/fetch-upload-streaming/). Any change this can be picked up, perhaps even soon?

[loeffel-io]

Webtransport support also shipped

[dunkymole]

An update on this this would be great.

[chris-kruining]

An update on this this would be great.

not as much an update as a note, I implemented a gRPC lib that uses both upload and download streaming (in my lib that is, somewhere in the stack it could still buffer, so no promises on actual duplexing, but I should be supporting it), you could take a look at that and see it if is usable for what you are doing.

A couple of notes / warnings: This is a new project, just 2 weeks old, so expect bugs (Issues and PR's are very much welcome). Whilst I am using this in the development for my app (and is working with what I use it for), I am the sole user as far as I know, ergo: no community. This lib implements gRPC, not gRPC-web, beware of that!

So, use on your own risk!

gRPC lib https://github.com/FYN-Software/grpc

protoc plugin to generate .ts files for your .proto files that is compatible with this lib https://github.com/FYN-Software/protoc-plugin-ts

docker container running the plugin and protoc https://hub.docker.com/r/chriskruining/protoc-all

p.s. motivation for telling all this is because I'd really love an extra pair of eyes looking at the code

[edaniels]

I did a simple proof of concept at https://github.com/jsmouret/grpc-over-webrtc More documentation to come but it is a start :)

There's https://github.com/viamrobotics/goutils/tree/main/rpc/examples/echo which has an example providing an RPC server over grpc, grpc-web, grpc-gateway and grpc-over-webrtc.

[loeffel-io]

any update?

[sampajano]

Thanks for the interest! No work is currently planned right now.. But will update if they are. Thanks! :)

[dyaskur]

So many people interested for this feature. Why is there no plan for it? May I know the reason?

[sampajano]

@dyaskur Hi thanks for the interest. I'll provide an update in the roadmap soon thanks!

[vladchuk]

Full support (including bi-di streaming) of gRPC in Flutter seems like a glaring omission indeed. And still no update on the road map - will there be such support at all?

[sampajano]

An update to the roadmap is provided in https://github.com/grpc/grpc-web/pull/1326. Thanks all for the patience and support! 😃

@vladchuk FYI :)

[bitnom]

need it before I start using in server apps

[pbower]

Hi, I'm very interested in this given Pyarrow's FlightRPC feature, as it opens up a number of high-performance data use cases. https://arrow.apache.org/docs/format/Flight.html Is the bidirectional streaming in the above roadmap (2023+) still being developed ?

Thanks!

[sampajano]

@pbower Thanks for checking! The bidirectional streaming support based on WebTransport is not currently being worked on yet but it's still planned as written. :)

We're making some changes soon to grpc-web including Typescript-ification so we'll probably get to that some time afterwards :)

[Lopamoko]

Hello! We are really looking forward to support for two-way data transfer in grpc from front-end to back-end via WebTransport. Please tell me, do you have any approximate understanding of when you will take on this? Now we cover this need using proxy: front-end -> WebSocket -> Proxy -> grpc -> BackEnd

[sampajano]

@Lopamoko Hi! Thanks for the interest and for checking! I cannot honestly give you a concrete date when this work will be started, since it's only planned but not really scheduled for this quarter or the next. Right now, i'm busy working on Typescript migration (first internal and external)which i'm hoping to finish later this year, and then I plan to improve on the set of fetch/stream performance / runtime related issues, before I have time to evaluate the bidi solution here. My optimistic hope is that I can start early next year. Hope this satisfies your question. :)

[popoolasubomi]

Hi guys, are there still any efforts to support bi-directional streaming? My use case involves a search bar with search suggestions based on text updates. I need the server to return a list of new query suggestions as the user changes text on the search bar

[sampajano]

@popoolasubomi Hi! Thanks for checking! My last comment is still mostly up-to-date status wrt bidi support. We weren't able to start any work on it yet because Typescript migration is still underway. I will update this thread when we begin to work on it. Thanks for your patience!

[popoolasubomi]

Do you have any recommendations we could use in the spare time? Till bidirectional streaming is complete? I heard about web transport with grpcs

[sampajano]

@popoolasubomi No sorry nothing from us (on web) unfortunately :) WebTransport is on our roadmap but it's not been implemented yet (it needs server (Envoy) support as well).

[oh-tarnished]

Hello all,

All our systems were written with full gRPC support. Recently, we started migrating our application to Svelte from Flutter. Midway through the process, we realized that the browser doesn't support all gRPC lifecycles. Here’s the workaround we implemented using tRPC.

Scenario: You have a gRPC server written in any language (most of our workarounds and supported gateways are in Go). Then, there's a Node-based server (tRPC) which contains the logic for the gRPC client (Node) and connects to the tRPC client on the browser (Svelte).

Note: This isn't the best approach for scalability. Since our application is intended to run locally, it works for us. However, I’m open to working on a more scalable solution if needed.

Please feel free to try it out and see how it goes!

Demo:

GitHub Repository