gRPC の特徴、REST との違い、SaaS での現実的な使い方をまとめる。

gRPC とは

Google が開発した RPC フレームワーク。Protocol Buffers でAPIを定義し、サーバー/クライアントのコードを自動生成する。

主な特徴

特徴 内容
Protocol Buffers JSON ではなくバイナリ形式。高速・軽量
スキーマ駆動 .proto で API を厳密に定義 → コード自動生成
HTTP/2 多重化、ヘッダー圧縮が標準
型安全 生成コードによりコンパイル時に型チェック

4つの通信パターン（REST との最大の違い）

1. Unary:          クライアント → サーバー（1リクエスト1レスポンス。REST と同じ）
2. Server Stream:  クライアント → サーバー →→→（サーバーが複数回返す）
3. Client Stream:  クライアント →→→ サーバー →（クライアントが複数回送る）
4. Bidirectional:  クライアント ⇄ サーバー（双方向ストリーム）

REST は基本 1 だけだが、gRPC は 2〜4 をネイティブにサポート。チャット、リアルタイムフィード、大量データの分割送信などに向く。

Reflection（エンドポイント一覧の取得）

gRPC にはサービス一覧を返す Reflection というオプション機能がある。有効にすると grpcurl -plaintext localhost:50051 list で一覧が取れる。REST でいう Swagger/OpenAPI の自動公開に近い。必須機能ではない。

ブラウザから直接叩けない

gRPC は HTTP/2 のフレームレベルを直接制御する必要があるが、ブラウザの fetch / XMLHttpRequest はそこまでの低レベル制御を公開していない。セキュリティの問題ではなく、ブラウザ API の制約。

回避策

方法 仕組み
gRPC-Web プロキシ（Envoy等）が gRPC ↔ ブラウザ互換形式に変換
gRPC-Gateway gRPC サービスの前に REST エンドポイントを自動生成
Connect buf が作った新プロトコル。HTTP/1.1 + JSON でも動く gRPC 互換

これらが存在する理由は、gRPC の開発体験（型安全なクライアント自動生成、スキーマ駆動、API仕様のズレが起きない）をフロントでも使いたいという要望から。

buf とは

.proto ファイルから Go 等のコードを自動生成するツール。従来の protoc のモダンな置き換え。

  従来 (protoc) buf
インストール protoc + 各言語プラグインを個別に buf 単体でOK
設定 シェルスクリプトで長いコマンド buf.yaml で宣言的
lint/breaking検出 なし 組み込み
依存管理 手動 buf.lock で管理

SaaS での使いどころ

gRPC が活きるケース

  • マイクロサービスが多数あり、サービス間通信が頻繁
  • リアルタイム性が必要（チャット、ライブ更新、IoT）
  • 大量データの高速処理（データパイプライン、ML推論）

gRPC が微妙なケース

  • サービス数が少ない（モノリス〜数個）
  • 主にブラウザ向けの CRUD アプリ
  • 外部開発者に API を公開したい
  • チームが小さい

現実的な構成

ブラウザ → REST or GraphQL → BFF → 内部は gRPC
                                     ↕
                                  マイクロサービス間

外向きは REST/GraphQL、内部通信だけ gRPC というハイブリッドが最も一般的。小〜中規模の SaaS で最初から全部 gRPC にするのはオーバーエンジニアリングになりがち。サービス間通信がボトルネックになった段階で導入するのが現実的。