プロトコル定義をバージョン管理して、安定性を確保する。

エンジニアリング

マイクロサービスがある場合、仕様が一致しないとプロトコルバッファファイルをアップデートするのを忘れてサーバー呼び出しを妨害するのは簡単です。サーバープロトコル署名(Proto)が定義と正確に一致しない場合、リクエストは失敗します。そのため、アプリケーション開発サイクル全体にわたって、スケーラブルなモデルパイプライン構造を設定することが重要です。

どうやってProtobufファイルを構成するか？

止するために、ファイル間で必要なモジュールをインポートすることができます。この点で、ファイルを作成し、npm（Node用のパッケージマネージャー）、Cargo、Composerのようなアプリケーション内で消費される依存関係マネージャーに送信するための中央の場所を設定することが役立つ場合があります。これに関する例は、ここで見つけることができ、npm（Nodeのためのパッケージマネージャ）を使用して、npm i @a11ywatch/protosを実行することでテストできます。node_modulesフォルダー内の定義ファイルが表示されます。

コンソールで `npm i @a11ywatch/protos` を使用してnpmからバッファプロトコルを使う。 — node_modulesフォルダー内にあるバッファファイルの例

Semverに従ったバージョン

gRPCにsemver（バージョン管理）に従うと、さまざまなレベルで真の互換性を確保するのに役立ちます。一般的に、gRPCの更新による互換性の破壊は発生しませんが、次の操作を実行する場合には発生します。

変更によって生成された破壊的なバイナリ

以下の変更は、gRPCプロトコルで破壊的な変更ではありませんが、クライアントは最新の.proto契約を更新した場合または最新のgRPCクライアントビルダーを使用した場合、更新する必要があります。バイナリ互換性は、gRPCライブラリをパッケージマネージャーを介して公開する場合に重要です。フィールドの削除-削除されたフィールドの値は、メッセージの未知のフィールド内に逆シリアル化されます。これは、gRPCプロトコルで破壊的な変更ではありませんが、クライアントは最新の契約を更新した場合に更新する必要があります。フィールド番号が、、将来的に誤って再利用されないようにするには、Protobufの予約済みキーワードを使用して、メッセージに削除されたフィールドの番号と名前を指定します。メッセージの名前変更 - メッセージ名は通常、ネットワークを介して送信されないため、gRPCプロトコルで破壊的な変更ではありません。ただし、クライアントは最新の契約を使用している場合、更新する必要があります。メッセージ名がネットワークを介して送信される場合は、Anyフィールドで発生します。メッセージタイプを識別するためにメッセージ名が使用される場合があります。メッセージの入れ子または入れ子を解除 - メッセージタイプは入れ子にすることができます。メッセージを入れ子にしたり、入れ子のメッセージを解除したりすると、そのメッセージの名前が変更されます。メッセージタイプの入れ子の方法を変更することは、名前変更と同じくらい互換性に影響を与えます。名前空間の変更 - 名前空間の変更は、生成された言語の型の名前空間を変更します。これは、gRPCプロトコルに破壊的な変更ではありませんが、クライアントは最新の契約を更新した場合に更新する必要があります。