gRPCの概要
- RPC (Remote Procedure Call) を実現するためにGoogleが開発したプロトコルの1つ
- IDL（インターフェース定義言語）を使ってあらかじめAPI仕様を .proto ファイルとして定義し、.protoファイルからサーバー側＆クライアント側に必要なソースコードのひな形を生成できる
- 言語に依存せず、一つの.protoファイルで12言語の実装を生成できる(Go, Java, Python, C, Ruby等など。主要なプログラミング言語はだいたい網羅されてる！)
- SSL通信がデフォルトで適応されており、安全性が高い
- スケーラビリティが高い (数百万のリクエストを並列でさばける)
マイクロサービスのAPIを用いる規模が大きく、サービス連携があるシステムでよく利用されている
- モダン、通信が早くて低遅延、データ送信が効率的
- 異なる言語間での通信を簡単にできる
gRPCはREST APIよりも高速な通信が可能
HTTP/2とProtocol Buffersを使っているので高速通信が可能とのこと。
HTTP/2の利用
HTTP/2を用いていることで4つのAPIタイプを作成でき、様々な種類/用途のAPIを開発できる
Protocol Buffers(Protobuf)の利用
構造化されたデータのシリアライズ方式の一種だそう。
プロセス内部の簡素なデータ構造をシリアライズするためにスキーマ定義用のドメイン固有言語があり、これが優秀なのでよく利用される。
以下のような形式らしい。
syntax = "proto3";
package example.protobuf;
message SimpleMessage {
message HeaderItem {
string name = 1;
string value = 2;
}
enum Type {
START = 0;
BLOB = 1;
END = 2;
}
uint64 id = 1;
Type message_type = 2;
repeated HeaderItem headers = 3;
bytes blob = 4;
}
Protocol Buffersの採用頻度が上がっている理由
- シンプルで可読性が高い
- プログラミング言語から独立で、任意のデータを表現できるわけではないが十分に適用可能範囲が広い
- すべてのニーズを満たそうとして仕様が複雑化していないため、実装間の意図せぬ非互換性で苦しめられることが少ない
- 周辺ツールを簡単に開発して不足仕様を自分で補える
buf
概要：protoファイルを扱うライブラリ
できること
- protoファイルのチェック：lint、フォーマット
- BSRへの登録/更新
設定ファイル
- buf.yaml：モジュールの定義。名前、依存関係、lint や breaking の設定の定義
- buf mod init で作成
- buf.work.yaml：高度なローカル開発機能であるワークスペースの定義
コマンド
Lint ＆ Format
buf lint buf format -w
protoを別リポジトリで運用する場合
- vendor配下にsparse checkout した他チームの proto配置
- これにより同レポジトリでレビューも可能
- parse checkout
- 特定ディレクトリだけをチェックアウトする方法
