gRPC
yuitaRPCとはAPIが提供したいサービスをprocedureとしてサーバー上に実装して、それをAPIを使うクライアントから直接呼び出すようにすること。簡単に言うとコンピュータ（クライアント）が別のコンピュータ（サーバー）上のプログラムを実行すること。
gRPCはRPCを具現化するための方式のひとつ。
gRPCは通信方式にHTTP/2を使用し、シリアライズ方式にProtocol Buffersを使用する。
通信方式について
RPCを行うためには以下の2つを行う必要がある。
・クライアントからサーバーに呼び出す関数と引数の情報を与える
・サーバーからクライアントに戻り値の情報を与える
gRPCでは、HTTP/2のPOSTリクエストとそのレスポンスを使ってこれを実現する。
・呼び出す関数の情報: リクエストのパスに含める
・呼び出す関数に渡す引数: HTTPリクエストボディに含める
・呼び出した関数の戻り値: HTTPレスポンスボディに含める
シリアライズについて
gRPCでは呼び出した関数の情報はプレーンテキストではなくProtocol Buffersによってシリアライズされた内容をリクエスト、レスポンスボディに含めることになっている。
一般的には、gRPCで呼び出そうとするProcedure(関数)をメソッド、そしてそのメソッドをいくつかまとめて一括りにしたものをサービスと呼ぶ。
Googleが定義して公開している便利な型の集合
gRPCで可能な4種類の通信方式
Unary RPC（1リクエスト、1レスポンス）
普通の通信
Server streaming RPC（1リクエスト、複数レスポンス）
サーバー側からプッシュ通知を受け取る場合など
Client streaming RPC（複数リクエスト、1レスポンス）
複数回に分けてアップロードしたデータをすべて受け取った後にサーバーが一度だけOKと返す場合など
Bidirectional streaming RPC（複数リクエスト、複数レスポンス）
WebSocketのような双方向通信など
yuita公式
yuitagRPCは高速なAPI通信とスキーマ駆動開発を実現する。
Remoto Procedure Call「遠隔手続呼び出し」
あるプログラムがネットワーク上の異なる場所に配置されたプログラムを呼び出して実行すること」
RESTはリソース思考を強く打ち出している。
リソース思考とはリソース（オブジェクト）を中心に考え、これに対してHTTPメソッドで操作していく考え方。
RPCではメソッドの呼び出しが基点となり、データはあくまでもその副産物なので
考え方としては逆。
思想、思考性の違いからRESTとgRPCは対比的に捉えられている。
RESTは規格ではなく原則。
RPCフレームワークは規格や仕様に沿って実装されたライブラリやフレームワーク。
gRPCの利点
HTTP/2による高速な通信
・Protocol Buffers
Protocol Buffersの一番の特徴は.protoファイルを書いてコンパイルすることで任意の言語のコードを生成してくれること。protoファイルのスキーマは静的型付け。
Protocol BuffersはgRPCの一番の利点と言える。
gRPCでは最初にprotoファイルにスキーマを書くので必然的にスキーマ駆動開発になる。
柔軟なストリーミング形式
gRPCのデメリット
HTTP/2が非対応の可能性がある
ブラウザで普通に使えない、Proxyサーバーなどを立てる必要がある。
RESTの方がSPAとの相性はいい。JSONとの親和性から。
言語ごとに機能の実装状況にばらつきがある。
バイナリにシリアライズされるとJSONのように読めない。
RESTの速さで十分な場合もある。
yuitaHTTP/2通信
通信時にデータがテキストからバイナリにシリアライズされて送られる。
gRPCではProtocol Buffers
一つのコネクションで複数のリクエスト、レスポンスをやり取りできる。
gRPCでもコネクションは常に張られっぱなしになる。
リクエストのたびに接続や切断を行う必要がなく、ヘッダーを都度送る必要がないので効率的な通信が行える。
高速な通信が行えることからサービスのボトルネックになりがちなマイクロサービス間の通信の遅延を防愚ことができる。