gRPC
https://gyazo.com/c11064b3a65bc96e62c89c6620807abf
なにこれ？
GoogleによるRPCの実装
RPCなので、クライアントでサーバのメソッドを直接呼び出すように扱うことができる
all the complexity of communication between different languages and environments is handled for you by gRPC
gRPC自体はプロトコルなのでHTTP/2以外でも実現できるが、HTTP/1.1はgRPCの要求を満たさないのでHTTP/2が利用されているらしい
学習リソース
チュートリアル
コード例つきで見やすい
import
messageの再利用
well-known-types
よく利用される定義済message
HTTP/2をしゃべるgRPCサーバを実装する
Protobufが先にオープンソースになっていたが、RPCの実装は外に出ていなかった
公式として出すまでは野良実装がいくつかあった
RPCでほしいTCPのアプリケーションレイヤーの機能はHTTP/2に入っている
gRPCはユーザのコードを呼ぶぐらい
多重化
TCPのコネクション1本の上を複数のリクエスト/レスポンスが同時に走る
いままではできなかったのでTCPのコネクションを何本もはっていた
順番が決まっていた
RPCではリソース使い過ぎてしまうので多重化が必須だった
プッシュができる
HTTP/2ではデータをちょっと（フレーム）づつ送りつけることができるので、これを利用する
gRPCでは「Stream」と呼ばれる
スピード優先で別リポジトリに同じ機能がたくさん生えた
kadoyau.icon 多分別チームで作ってるから汎用的でない＆コミュニケーションコスト自分で作ったほうが早いという構造がある
同一リポジトリに関連機能をはやした
リリースに含まれるコミット数が多くなる=障害頻度が上がる&切り戻しが大変→リリース頻度が落ちた
kadoyau.icon このあたり具体的な組織がわからないが、文面から類推するにたぶんチームの人数が増え、異なるチームが一つのリポジトリに相乗りしていたのだと思う
microservices化を目論む
1. 開発スピードの向上：更新を限定的にして、障害発生リスク＆調査コストを減らす
2. 横断的な機能を共通基盤にする
再利用性が向上する機能を切り出す
今後伸ばしたい機能を切り出す