gRPCとは
gRPCの概要を簡単にまとめる。
- HTTP/2による高速な通信
- IDL(Protocol Buffers)でデータ構造とRPCを定義
- 多言語対応のソースコード自動生成
- Streamingを用いた双方向通信が可能
詳細は以下へ。
gRPC-Webとは
gRPC-WebによってgRPC通信をWebでも使うことができる。以上！
といえればいいのだが、実際は、ブラウザの制限にあわせたプロトコルを定義している。
そのため、現時点だと、プロトコル間の微調整を行うためのプロキシが必要で、公式ではEnvoyを推奨していたりする。
ブラウザの制限
前述したブラウザの制限とは、例えば以下のようなものだ。
- HTTP/2のフレーミングレイヤーはブラウザに露出されない
- ブラウザからのStreamingがまだ不十分 (WHATWG Streams)
- クライアントにHTTP/2の使用を強制できない
- クロスブラウザで動くbase64のようなテキストエンコーディングの必要性
上記により、以下のようなことがgRPC-Webでは不可能である。
- gRPCでサーバーとの「直接」通信 (Proxyを用意する必要がある)
- Client-side & Bi-directional streaming
少なくともBi-directional streamingがでできるようになればgRPC-Webの立場はかなり上がると思うので残念だ。
メリット
現時点でのgRPC-Webのメリットは以下のようなものがある。
- クライアントからサーバーまで、一気通貫でgRPCの開発パイプラインに載せられる
- バックエンド・フロントエンド間でタイトな連携ができる
- クライアント向けの「gRPCライブラリ」を容易に生成できる
例えば、バックエンドのサービス群がgRPCで構築されている時、HTTPのレイヤーでBFFを用意する必要がなくなり、不要なAPI設計やコミュニケーションをへらすことができるのがメリットになりそうだ。
下の2つは、IDLベースなこととコードの自動生成により、RESTなどで「仕様書ベース」で合意を行うよりも、スムーズな開発ができるということだと理解した。アプローチや思想は異なるが、GraphQLとも一部ゴールを共有しそうだ。
gRPC APIの設計
API設計のガイドラインをGoogleが用意していたりする。
使ってみた
実際にgRPC-Webをつかって簡単なチャットを作ってみた↓