JS API bidi stream abstraction #1049
Comments
niloc132
added a commit
that referenced
this issue
Aug 27, 2021
Fetch/h2-based grpc-web clients do not support bidirectional streaming at this time, but the websocket client we are using from https://github.com/improbable-eng/grpc-web/ does. This lets us keep a single websocket open instead of making many calls. The client has support now to abstract how a bidirectional stream is created, either by a single websocket, or by a pair of fetch calls. Additionally, autocomplete was seeing problems that appeared related to the server-side grpc handling payloads out of order. These methods have been consolidated into a single bidirectional stream to ensure ordering is sane. The server now has support to only implement a bidirectional stream once, and mark the "open"/"next" rpc methods as part of that, and automatically have their requests enqueued to be handled serially. Other improvements got slipped into this work as well, such as only interacting with autocomplete from the gRPC service and never from DB, so that dependency was cut (as well as the dependency on gRPC utils, which only existed to get jsr305 annotations into various projects). The client is incomplete in this patch, we plan on continuing this work as part of #730. Fixes #929 Fixes #834 Fixes #1049
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When we are using websockets for grpc, we can actually support bidi streams, but when using ssl we will use http2/fetch we have to fall back to the server-stream and unary pair, with barrage wrapper to handle sequencing. The client should have an abstraction to let doput/subscription/autocomplete not care what the underlying transport is, but handle sending and receiving in a consistent way.
The text was updated successfully, but these errors were encountered: