gRPC 1.0于2016年8月发布，此后已成长为应用程序通信的主要技术解决方案之一。它已被全球范围内的初创企业，企业公司和开源项目采用。它对多语言环境的支持，对性能，类型安全性和开发人员生产力的关注，已经改变了开发人员设计架构的方式。

到目前为止，收益基本上仅适用于移动应用程序和后端开发人员，而前端开发人员则不得不继续依赖JSON REST接口作为其主要的信息交换手段。但是，随着gRPC-Web的发布，gRPC有望成为前端开发人员工具箱中有价值的补充。

在本文中，我将介绍浏览器中gRPC的一些历史，探索当今的世界状况，并分享对未来的一些想法。

开端

在2016年夏季，Google和Improbable 1的团队分别开始致力于实现可称为“浏览器的gRPC”的东西。他们很快发现了彼此的存在，并在一起为新协议定义了规范2。

gRPC-Web规范

当前不可能在浏览器中实现HTTP / 2 gRPC spec 3，因为根本没有浏览器API能够对请求进行足够的细粒度控制。例如：无法强制使用HTTP / 2，即使存在浏览器，原始HTTP / 2框架也无法访问。gRPC-Web规范从HTTP / 2规范的角度出发，然后定义差异。这些主要包括：

• 同时支持HTTP / 1.1和HTTP / 2。
• 在请求/响应主体的末尾发送gRPC预告片，如gRPC消息标头4中的新位所示。
• 在gRPC-Web请求和gRPC HTTP / 2响应之间进行转换的必需代理。

科技

基本思想是让浏览器发送正常的HTTP请求（使用Fetch或XHR），并在gRPC服务器的前面有一个小的代理，以将请求和响应转换为浏览器可以使用的内容。

两种实现

在谷歌与不可能的团队都继续实行两种不同的存储库的规格5，6，和略有不同的实现方式，这样既完全符合规范，并在相当长的时间也不是与代理对方的兼容7，8。

Improbable gRPC-Web客户端9在TypeScript中实现，并在npm上以@improbable-eng/grpc-web10提供。还有一个Go代理，既可以作为可导入现有Go gRPC服务器11的包，也可以作为可用于将任意gRPC服务器公开给gRPC-Web前端12的独立代理。

使用Google Closure库14库以JavaScript实现Google gRPC-Web客户端13。它在npm 15可用。它最初随附实现为NGINX扩展16的代理，但此后又扩展了Envoy代理HTTP过滤器17，该过滤器自v1.4.0起在所有版本中都可用。grpc-web

功能集

gRPC HTTP / 2实现均支持四种方法类型：一元，服务器端，客户端和双向流。但是，gRPC-Web规范并没有明确要求任何客户端或双向流支持，而只是在浏览器中实现了WHATWG流18后才实现。

Google客户端支持一元和服务器端流，但仅在与grpcwebtext模式一起使用时才支持。该grpcweb模式仅完全支持一元请求 。这两种模式指定了在请求和响应中编码原生缓冲区有效载荷的不同方法。

Improbable客户端支持一元流和服务器端流，并且具有一种实现方式，可以根据浏览器功能自动在XHR和Fetch之间进行选择。

下表总结了支持的不同功能：

有关此表的更多信息，请参见 我在github上的兼容性测试库。

兼容性测试可能会演变成某种自动化测试框架，以在将来强制实施和记录各种兼容性。

相容性问题

当然，使用两个不同的代理也会出现兼容性问题。幸运的是，最近已经解决了这些问题，因此可以期望将任一客户端与任一代理一起使用。

未来

Google实施于2018年10月21公布了1.0版并全面上市，并发布了未来目标的路线图22，其中包括：

• 高效的类似于JSON的消息编码
• 适用于Node，Python，Java等的进程内代理
• 与流行的框架（React，Angular，Vue）集成
• 提取API传输以实现内存高效流
• 双向蒸煮支持

Google正在寻找对社区重要的功能的反馈，因此，如果您认为其中任何一项对您特别有价值，请填写其调查23。

这两个项目之间最近的谈判已达成共识，即将Google客户端和Envoy代理推广为新用户的首选解决方案。Improbable客户端和代理将保留为该规范的替代实现，而无需依赖Google Closure，但应将其视为试验性的。将会为现有用户制作迁移指南，以迁移到Google客户端，并且各个团队正在共同努力以汇聚生成的API。

结论

Google客户端将继续以稳定的步伐实施新功能和修复，并由一个致力于其成功的团队组成，并且它是gRPC的官方客户端。它不像Improbable客户端那样没有Fetch API支持，但是如果这对社区来说是重要的功能，那么它将被添加。Google团队和更大的社区正在与官方客户合作，以​​使gRPC社区整体受益。自从GA宣布以来，社区对Google gRPC-Web repo的贡献已大大增加。

在两个代理之间进行选择时，功能没有差异，因此这取决于部署模型。Envoy将适合某些情况，而进程内Go代理具有其自身的优势。

如果您今天刚开始使用gRPC-Web，请首先尝试使用Google客户端。它具有严格的API兼容性保证，并建立在Gmail和Google Maps使用的坚固的Google Closure库基础上。如果您需要Fetch API内存效率或实验性Websocket客户端和双向流传输，则Improbable客户端是一个不错的选择，并且在可预见的将来，Improbable将继续使用和维护它。

无论哪种方式，gRPC-Web都是Web开发人员的绝佳选择。它为浏览器带来了复杂协议的可移植性，性能和工程性，对于前端开发人员来说是一个激动人心的时刻！

参考文献

1. improbable.io/games/blog/grpc-web-moving-past-restjson-towards-type-safe-web-apis ↩
2. github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md ↩
3. github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md ↩
4. github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md#protocol-differences-vs-grpc-over-http2 ↩
5. github.com/improbable-eng/grpc-web ↩
6. github.com/grpc/grpc-web ↩
7. github.com/improbable-eng/grpc-web/issues/162 ↩
8. github.com/grpc/grpc-web/issues/91 ↩
9. github.com/improbable-eng/grpc-web/tree/master/client/grpc-web ↩
10. npmjs.com/package/@improbable-eng/grpc-web ↩
11. github.com/improbable-eng/grpc-web/tree/master/go/grpcweb ↩
12. github.com/improbable-eng/grpc-web/tree/master/go/grpcwebproxy ↩
13. github.com/grpc/grpc-web/tree/master/javascript/net/grpc/web ↩
14. developers.google.com/closure ↩
15. npmjs.com/package/grpc-web ↩
16. github.com/grpc/grpc-web/tree/master/net/grpc/gateway ↩
17. envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/grpc_web_filter ↩
18. stream.spec.whatwg.org ↩
19. Improbable客户端通过实验性的websocket传输支持客户端和双向流。这不是gRPC-Web规范的一部分，不建议用于生产环境。↩
20. grpcweb允许调用服务器流方法，但是直到流关闭后才返回数据。↩
21. GRPC的Web一般可 ↩
22. github.com/grpc/grpc-web/blob/master/doc/roadmap.md ↩
23. docs.google.com/forms/d/1NjWpyRviohn5jaPntosBHXRXZYkh_Ffi4GxJZFibylM ↩

• ←上一个