gRPC
RPCとは
Remote Procedure Call の略
手元のプログラムから、遠隔にあるプログラムに要求を出して処理を実行してもらい、その結果をもらうという流れ。
遠隔地 = 物理的に離れた場所かもしれないし、同一マシン内かもしれない。問わない。
APIとの違いは?
APIはより抽象的の概念であり、RPCは設計パラダイム・アプローチである。
HTTPとの違いは?
HTTPは通信プロトコル(どう通信するか)、RPCは設計思想(どう設計するか)。
レイヤーが異なるため、組み合わせて使用可能。
リモートプロシージャコール (RPC) と REST は API 設計の 2 つのアーキテクチャスタイルです。
REST APIは「リソース」を中心に設計する。
RPC APIは「処理」を中心に設計する。
どちらもAPI設計のアーキテクチャスタイル。
code: 関係図
API設計パラダイム
├── REST(リソース指向)
│ └── 通常はHTTPで実装
│ └── GraphQL over HTTP
└── RPC(関数呼び出し指向)
├── gRPC(HTTP/2ベース)
├── JSON-RPC(HTTPベース)
└── 独自プロトコルベース
ただ、RPCというのが重要なのではなく、次のgRPCというのが重要である。 gRPCとは
Googleが開発したRPCを実現するフレームワーク。
ただし、単に「RPCを実現しました」というのではない。Googleが大規模システムで抱えていた課題を解決してきた実績の元できたフレームワークである。
ポイント
2. protobuf定義に基づく型安全なAPI管理で、破壊的変更を防止
code: イメージ
サーバー側でAPI変更
↓
.protoファイル更新
↓
クライアント側で再コンパイル
↓
型不整合があれば即座にエラー 🔴
↓
本番リリース前に発見・修正
大規模システムだと、通信網が入り組んでいて、よくあるREST APIでは破壊的変更を防ぐのが難しくなる。
なので、機械的に防げるgRPCの方が良いということになる。
3. HTTP/2ベースの通信により、ストリーミング・多重化・効率的な接続管理が可能
gRCPの通信パターンは複数ある
これを頭の隅に押さえておけばいい。
必要になるまでは適当に理解しとけい。
以上を踏まえて以下あたりも読んでみては
RPCとは、遠隔手続き呼び出し(Remote Procedure Call)を略して、RPCと呼びます。
遠隔手続き呼び出しとは、手元のプログラム・マシン(クライアント)から要求を送信して、遠隔地にあるプログラム・マシン(サーバ)に実装されている処理を実行し、その結果をクライアントに呼び出すことを指します。ここでいう遠隔地は物理的に離れたサーバかもしれませんし、同一PC上で動作しているサーバになるかもしれません。
そうだな。
q.icon でも、それってHTTP、REST APIと言われてるものと何が違うの?
gRPCでは、データのやりとりにProtocol Buffersを使用します。Protocol Buffersは言語中立的なデータフォーマットであり、異なるプログラミング言語間でのデータのやり取りを可能とするための共通のデータ表現を持ちます。類似する形式としては、JSONなどがありますが、JSONはテキスト形式であるのに対して、Protocol Buffersはバイナリ形式(情報を0と1で表す形式)に変換されるため、データ量が小さく、転送が高速で行われます。
デファクトスタンダードだと思われる。
バイナリ形式らしく、データ量が小さくて、転送が高速なんだって。