25
Help us understand the problem. What are the problem?

More than 1 year has passed since last update.

posted at

updated at

Organization

3分でわかるgRPC-Web

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をつかって簡単なチャットを作ってみた↓

参考

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Sign upLogin
25
Help us understand the problem. What are the problem?