瀏覽器引入gRPC的現況

做者：Johan Brandhorst

gRPC 1.0於2016年8月發佈，現已發展成爲應用通訊的首選技術解決方案之一。它已被全球的初創公司、企業公司和開源項目採用。它對多語言環境的支持、關注性能、類型安全性和開發者生產力已經改變了開發者設計架構的方式。

到目前爲止，基本上只有移動應用程序和後端開發者得到這些好處，而前端開發者不得不繼續依賴JSON REST接口做爲其主要的信息交換方式。然而，隨着gRPC-Web的發佈，gRPC有望成爲前端開發者工具箱中的有價值補充。

在這篇文章中，我將描述gRPC在瀏覽器中的一些歷史，探索當前的狀態，並分享對將來的一些見解。

初期

在2016年夏天，Google和Improbable（1）的團隊獨立地開始實施能夠稱爲「瀏覽器的gRPC」的東西。他們很快發現了彼此的存在，並聚在一塊兒爲新協議定義了規範（2）。

gRPC-Web規範

目前沒法在瀏覽器中實現HTTP/2 gRPC規範（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服務器前面有一個小代理，將請求和響應轉換爲瀏覽器可使用的內容。

兩個實現方式

Google和Improbable的團隊在兩個不一樣的存儲庫中實現了規範（5,6），而且採用了稍微不一樣的實現，它們都不徹底符合規範，在很長一段時間內都不兼容另外一個代理（7,8）。

Improbable的gRPC-Web客戶端（9）以TypeScript實現，能夠在npm上以grpc-web-client（10）得到。還有一個Go代理可用，既可做爲導入現有Go gRPC服務器的軟件包（11），也可做爲獨立代理，將任意gRPC服務器暴露給gRPC-Web前端（12）。

Google的gRPC-Web客戶端（13）使用Google Closure庫（14）以JavaScript實現，能夠在npm上以grpc-web（15）得到。它最初附帶做爲NGINX擴展實現的代理（16），但後來在Envoy代理HTTP過濾器（17）上提供，該過濾器自v1.4.0以來在全部版本中均可得到。

功能集

gRPC HTTP/2的實現都支持四種方法類型：一元（unary）、服務器端、客戶端和雙向流。可是，gRPC-Web規範並未強制要求任何客戶端或雙向流支持，只是在瀏覽器中實現WHATWG Streams（18）後纔會實現。

Google客戶端支持一元和服務器端流，但僅在與grpcwebtext模式一塊兒使用時才支持。grpcweb模式只徹底支持一元請求。這兩種模式指定了在請求和響應中編碼protobuf有效負載的不一樣方法。

Improbable客戶端支持一元和服務器端流，而且實現根據瀏覽器功能在XHR和Fetch之間自動選擇。

這表格總結了支持的不一樣功能：

有關此表格的更多信息，請參閱我在github上的兼容性測試repo。

兼容性測試可能演變爲一些自動化測試框架，以便在未來強制執行和記錄各類兼容性。

兼容性問題

固然，有兩個不一樣的代理也會出現兼容性問題。幸運的是，最近已經解決了這些問題，所以你能夠指望將任一客戶端與任一代理一塊兒使用。

將來

Google的實施在2018年10月（21）公佈了版本1.0和通常可用性，並公佈了將來目標的路線圖（22），包括：

• 相似JSON的有效消息編碼
• Node、Python、Java等的進程內代理
• 與流行框架集成（React、Angular、Vue）
• Fetch API傳輸以實現內存高效的流式傳輸
• 雙向流支持

Google正在尋求有關哪些功能對社區很重要的反饋，若是你認爲其中任何一項對您特別有價值，請填寫他們的調查（23）。

兩個項目最近的對話已經贊成將Google客戶端和Envoy代理做爲新用戶的首選解決方案。Improbable的客戶端和代理將做爲規範的替代實現，而不依賴於Google Closure，但應被視爲實驗性的。將爲現有用戶生成遷移指南，以便遷移到Google客戶端，團隊也正在共同協做所生成的API。

結論

Google客戶端將繼續以穩定的速度實施新的功能和修復，其團隊致力於成功，而且它是官方的gRPC客戶。它沒有像Improbable客戶端那樣的Fetch API支持，但若是這是社區所需的一個重要功能，它將被添加。Google團隊和更大的社區正在爲官方客戶端進行合做，以使gRPC社區受益。自GA宣佈以來，社區對Google gRPC-Web存儲庫的貢獻大幅增長。

在兩個代理之間進行選擇時，功能沒有區別，因此它成爲你部署模型的問題。Envoy將適合某些場景，而進程中的Go代理有其自身的優點。

若是你今天開始使用gRPC-Web，請先試用Google客戶端。它具備嚴格的API兼容性保證，並創建在Gmail和Google Maps使用的堅如磐石的Google Closure庫基礎之上。若是你須要Fetch API的內存效率，或實驗性的websocket客戶端和雙向流，Improbable客戶端是一個不錯的選擇，而且在可預見的將來繼續由Improbable使用和維護。

不管哪一種方式，gRPC-Web都是Web開發者的絕佳選擇。它將複雜協議的可移植性、性能和工程設計引入瀏覽器，併爲前端開發者帶來激動人心的時刻！

參考文獻

1. https://improbable.io/games/b...
2. https://github.com/grpc/grpc/...
3. https://github.com/grpc/grpc/...
4. https://github.com/grpc/grpc/...
5. https://github.com/improbable...
6. https://github.com/grpc/grpc-web
7. https://github.com/improbable...
8. https://github.com/grpc/grpc-...
9. https://github.com/improbable...
10. https://www.npmjs.com/package...
11. https://github.com/improbable...
12. https://github.com/improbable...
13. https://github.com/grpc/grpc-...
14. https://developers.google.com...
15. https://www.npmjs.com/package...
16. https://github.com/grpc/grpc-...
17. https://www.envoyproxy.io/doc...
18. https://streams.spec.whatwg.org/
19. The Improbable client supports client-side and bi-directional streaming with an experimental websocket transport. This is not part of the gRPC-Web spec, and is not recommended for production use.
20. grpcweb allows server streaming methods to be called, but it doesn’t return data until the stream has closed.
21. https://grpc.io/blog/grpc-web-ga
22. https://github.com/grpc/grpc-...
23. https://docs.google.com/forms...