From 7b6e8ed491deaebbea2bcc50f4a70eb06e8a04b4 Mon Sep 17 00:00:00 2001 From: Eryu Xia Date: Wed, 22 Mar 2023 14:04:45 -0700 Subject: [PATCH] Roadmap update (Bi-di Streaming) (#1326) --- doc/roadmap.md | 26 +++++++++++----------- doc/streaming-roadmap.md | 47 +++++++++++++++++++--------------------- 2 files changed, 35 insertions(+), 38 deletions(-) diff --git a/doc/roadmap.md b/doc/roadmap.md index 133598d..5af7c68 100644 --- a/doc/roadmap.md +++ b/doc/roadmap.md @@ -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. diff --git a/doc/streaming-roadmap.md b/doc/streaming-roadmap.md index 071f17f..df7e173 100644 --- a/doc/streaming-roadmap.md +++ b/doc/streaming-roadmap.md @@ -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. \ No newline at end of file