操作して学ぶ

gRPCフロー可視化

gRPC には4つの呼び出し方があります。どれも HEADERS → DATA → TRAILERS という骨格は同じで、DATA が何回流れるかだけが違う—— それを4パターンのシーケンス図で見比べてください。矢印をクリックすると、そのフレームの説明が出ます。

rpc GetUser(Request) returns (Response)

1リクエスト → 1レスポンス。もっとも基本の形で、REST の1回の呼び出しに近い。

HEADERS（メソッド・メタデータ）DATA（protobufメッセージ）TRAILERS（grpc-status）何度でも流れる

HEADERSクライアント → サーバー

HEADERS: :path /user.UserService/GetUser, content-type: application/grpc

呼ぶメソッドをパスで指定し、メタデータ（認証トークンなど）もヘッダで送る。

図の矢印をクリックすると、そのフレームの説明に切り替わります（1 / 6）。

向く用途

一般的なCRUD、参照系API。REST の GET/POST に相当する用途。

似た技術との違い

REST との違いは、本文が protobuf バイナリで型が定義から決まること、HTTP/2 上で多重化されること、ステータスがトレーラで返ること。

押さえどころ

4パターンの違いは「stream がどちらに付くか」だけ。rpc F(stream A) returns (stream B) の定義で、リクエスト側・レスポンス側のstream の有無が、そのまま DATA の繰り返し回数になります。
ステータスはトレーラで返る。HTTP としては先に 200 が返り、 gRPC としての成否は最後の grpc-status で確定します。ストリーミングでは「途中まで送ってから失敗」がありうるので、この設計が必要になります。
土台は HTTP/2 の多重化。1本のTCP接続の上に複数のストリームが並走するので、 RPCごとに接続を張り直しません。だから gRPC は素の HTTP/1.1 では成立しない——ブラウザから直接呼べず gRPC-Web というプロキシ前提の変種がある理由もここにあります。
REST との住み分け。型が定義（.proto）から生成され、バイナリで軽く、ストリーミングが標準にあるのが gRPC の強み。一方でブラウザからの直接利用、人間が読める本文、キャッシュのしやすさは REST が有利です。