grpc
/
grpc-web
mirror of https://github.com/grpc/grpc-web.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Roadmap update (Bi-di Streaming) (#1326)

This commit is contained in:
Eryu Xia 2023-03-22 14:04:45 -07:00 committed by GitHub
parent b1297e616a
commit 7b6e8ed491
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 35 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
doc/roadmap.md
View File

@ -1,9 +1,9 @@
# Overview
# gRPC-Web Roadmap
The purpose of this document is to collect all the features that we believe are
useful for gRPC users.
# Background
## Background
gRPC-Web has been developed internally at Google as part of the front-end
stacks for Google's Web applications and cloud services. Over time we plan to
@ -16,9 +16,9 @@ everything, we also need keep the balance between creating a reusable and stable
open-source solution and meeting those requirements unique to Google's Web applications
(such as search).
# Roadmap Features (in no particular order)
## Roadmap Features (in no particular order)
## Non-Binary Message Encoding
### Non-Binary Message Encoding
The binary protobuf encoding format is not most CPU efficient for browser
clients. Furthermore, the generated code size increases as the total protobuf
@ -28,7 +28,7 @@ For Google's Web applications (e.g. gmail), we use a JSON like format which is
comparable to JSON in efficiency but also very compact in both the message size
and code size.
## Streaming Support
### Streaming Support
Currently the gRPC-Web client library uses XHR to ensure cross-browser support
and to support platforms such as React-Native.
@ -40,11 +40,11 @@ However, fetch still has certain gaps compared to XHR, most notably the lack of
cancellation support. Progressing events, I/O event throttling are other
concerns.
## Bidi Streaming
### Bidi Streaming
See the dedicate road-map doc on [bidi streaming](streaming-roadmap.md).
We plan to leverage [WebTransport](https://web.dev/webtransport/) for bi-directional streaming. Also see the dedicate road-map doc on [bidi streaming](streaming-roadmap.md).
## Security
### Security
We plan to publish a comprehensive guideline doc on how to create secure Web
applications.
@ -52,7 +52,7 @@ applications.
Native support such as XSRF, XSS prevention may also be added to the gRPC-Web
protocol.
## In-process Proxies
### In-process Proxies
[In-process proxies](https://github.com/grpc/grpc-web/blob/master/doc/in-process-proxy.md)
will eliminate the need to deploy Envoy to use gRPC-Web.
@ -63,7 +63,7 @@ gRPC-Web proxy.
To minimize maintenance overhead, we will only support Envoy as the official proxy for gRPC-Web.
## Web Framework Integration
### Web Framework Integration
This is to provide first-class support for gRPC API and gRPC-Web in popular Web
frameworks such as Angular.
@ -71,18 +71,18 @@ frameworks such as Angular.
Note Dart gRPC will use gRPC-Web as the underlying implementation on the
Dart Web platform.
## TypeScript Support
### TypeScript Support
We now have experimental TypeScript Support! See the main README for more
information.
## Non-Closure compiler support
### Non-Closure compiler support
With the addition of CommonJS style imports, gRPC-Web client stubs can now be
compiled with various tools such as Browserify, Webpack, etc. Let us know
what else we should try!
## Web UI Support
### Web UI Support
This allows the user to construct and submit a gRPC request directly using the
browser.

47
doc/streaming-roadmap.md
View File

@ -1,42 +1,39 @@
# Overview
# Streaming Roadmap
This document describes the road-map for gRPC-Web to support different streaming features.
* Server-streaming
* Client-streaming and half-duplex streaming
* Full-duplex streaming over HTTP
* Full-duplex streaming over Web-transport
* Full-duplex streaming over WebTransport
# Server-streaming
## Server-streaming
We will keep improving server-streaming in the following areas:
* Finalizing keep-alive support (via Envoy) - 2020
* Performance improvements and whatwg Fetch/streams support, including service workers - 2020
* Addressing runtime behavior gaps between Fetch and XHR - 2020+
* Fetch cancellation support - 2023
* Finalizing keep-alive support (via Envoy) - 2023+
* Performance improvements and whatwg Fetch/streams support, including service workers - 2023+
* Addressing runtime behavior gaps between Fetch and XHR - 2023+
# Client-streaming and half-duplex streaming
## Client-streaming and half-duplex streaming
We are actively involved in the Chrome [Origin Trial](https://developers.chrome.com/origintrials/#/view_trial/3524066708417413121)
to finalize the fetch/upload stream API spec (whatwg). One of the pending issues that blocks the final spec is to decide whether it is safe to enable
upload-streaming over HTTP/1.1. We believe that upload-streaming should be enabled for both HTTP/2 and HTTP/1.1. Specifically for gRPC-Web, the server can't control
the client deployment. As a result, if upload-streaming is only enabled over HTTP/2, a gRPC service will have to implement a non-streaming method
as a fallback for each client-streaming method.
We don’t plan to support client-streaming via Fetch/upload-streams (See [Appendix](#chrome-origin-trial-on-upload-streaming) on backgrounds on the Chrome Origin Trial). As a result, half-duplex bidi streaming won’t be supported via Fetch/streams either.
Once the whatwg spec is finalized and upload-streaming is supported by major browsers (2020), we will add client-streaming support
in gRPC-Web (and Envoy) which will also enable half-duplex bidi streaming support.
Client-streaming and half-duplex bidi streaming will be addressed when Full-duplex streaming is supported via WebTransport (see below).
# Full-duplex streaming over HTTP
## Full-duplex streaming over WebTransport
It is possible to support bidi communication over dual HTTP requests, one for download-streaming and the other for upload-streaming,
similar to what's implemented by Google to support the [W3C Speech API](https://wicg.github.io/speech-api/).
We will be leveraging [WebTransport](https://web.dev/webtransport/) to enable full-duplex (bi-directional) streaming. Planned for 2023+.
Once client-streaming is supported in gRPC-Web, we will publish a spec to enable bidi streaming over dual HTTP requests and implement the complete support in Envoy (2020+).
# Full-duplex streaming over Web-transport
We are working with the Chromium Blink team to evaluate how to leverage this whole new transport and QUIC. Stay tuned.
# Issues with WebSockets
## Issues with WebSockets
We have no plan to support full-duplex streaming over WebSockets (over TCP or HTTP/2). We will not publish any experimental spec for gRPC over WebSockets either.
The main issue with WebSockets is its incompatibility with HTTP, i.e. the ubiquitous Web infrastructure. This means HTTP fallback is always needed. Recent IETF proposal to tunnel WebSockets over HTTP/2 is not widely implemented either.
## Appendix
### Chrome Origin Trial on `upload-streaming`
We worked on a Chrome [Origin Trial](https://developers.chrome.com/origintrials/#/view_trial/3524066708417413121)
to finalize the fetch/upload stream API spec (whatwg). One of the pending issues that blocks the final spec is to decide whether it is safe to enable
upload-streaming over HTTP/1.1. We believe that upload-streaming should be enabled for both HTTP/2 and HTTP/1.1. Specifically for gRPC-Web, the server can't control the client deployment. As a result, if upload-streaming is only enabled over HTTP/2, a gRPC service will have to implement a non-streaming method
as a fallback for each client-streaming method.