gRPC
概要 †
- RPCでは、IDL（インターフェース定義言語）を使ってあらかじめAPI仕様を .proto ファイルとして定義し、そこからサーバー側＆クライアント側に必要なソースコードのひな形を生成する
- 言語に依存しないIDLで先にインタフェースを定義することで、様々なプログラミング言語の実装を生成できるというメリットがある
- 通信プロトコルには HTTP/2 が使われる
- HTTP/2 が使われているので、クライアントとサーバー間のリクエストとレスポンスは 1:1 だけでなく 1:* や *:* などの通信が可能
- クライアントからのリクエストで複数のメッセージを投げられて、サーバーから複数メッセージを返すなどの通信が可能になる
- HTTP/2 の機能の1つであるストリーム（同一の TCP 接続でクライアントとサーバーが双方向にデータをやりとり出来る仕組み）のおかげ
- Protocol buffers でデータをシリアライズ化してやりとりする
- 型付けされたメッセージの他に key-value（value は複数設定可能）で定義可能なメタデータというものも存在しており、HTTP ヘッダのように扱うことができる
- 利用例としては、不正なリクエストかの判断を行うための認証情報や、複数のサービスを横断する処理をトレースする ID などをハンドリングするケースが挙げられる
Go †
- 数千行のコードで、基本的なところは１パッケージにまとまっている。生成されたコードも少ない
- net/httpのサーバー、クライアントともに、http.Handler、http.Clientを利用しているため、サードパーティのライブラリを駆使しやすい
- gRPC、gRPC-Web、およびConnect独自のプロトコルの3つを最初からサポートしたサーバー、クライアントが作れる。プロキシは不要。Connect独自のプロトコルはREST APIになっていてcurlで簡単にテスト可能。もちろんgrpcurlも可能。
- Connectを開発したのは、Protobufからのコード生成やら、linterやら、いろいろやりやすくしてくれるツールであるbufを開発したところ。Protobufを知り尽くしているところが作ったライブラリ。
- grpc-gateway は gRPC サーバの前段に立つリバースプロキシです
- gRPC（protobuf）の通信を application/json な API に変換してくれます．
ASP.NET Core gRPC †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
