研修中の質疑応答をまとめたものです。
- フィールドのバリデーションはどうするべき？
- 互換性が保てないときはどうすればよい？
- サーバー側からも keep-alive でクライアントの死活確認できる？
- package に指定する名前が他のプログラムと被ったらどうなる？
- ネットワークが切れるとデッドラインやキャンセルはどうなる？
Protocol Buffers のメッセージのフィールドはすべてオプショナルです。 前方・後方互換性を維持するために、バリデーションする際にはまずゼロ値を極力受け付けるようにしましょう。 ゼロ値とは文字列なら空文字列、bool なら false、数値なら 0 です。
バリデーションの実装自体はサーバーの実装の中で普通に書いて良いです。
github.com/envoyproxy/protoc-gen-validate のように proto ファイルにルールを書く仕組みもありますが、alpha とのことなので留意して使いましょう。
どうしても互換性が保てない変更をするときは、新しい API を別のパッケージないし service として定義しましょう。 gRPC サーバーは複数の service を同時に提供できるため、こうすることでクライアントが古い API から新しい API に移行する時間の余裕を与えることができます。
全てのクライアントが新 API に切り替わったら、古い API の提供を止めましょう。
できます。
Go なら grpc.NewServer(grpc.KeepAliveParams{...}) と指定します。
package 名は HTTP/2 の :path 疑似ヘッダの値になるため、複数の gRPC サービスをロードバランサで PATH ベースで振り分ける際に問題になる可能性があります。
ドメイン名のような形式にして被らないようにするのがお勧めです。
デッドライン設定は RPC 開始時に渡っているため、クライアントとの通信が途絶えても有効に働きます。
キャンセルは、クライアントからシグナルが飛ばないので動きません。