3

メッセージング レイヤーを提供する gRPC を使用して新しいプラットフォームを構築しています。これにより、API がサポートすることが期待される機能の完全なセットが最終的に公開されます。

私たちはインターフェースに名前を付けるための最良のパターンを決定しようとしています。

私たちが行っていることの簡単な例には、ユーザーの作成、更新、および取得が含まれます。現在のサービスの例を次に示します。

service Users {
  rpc GetUser(UserRequest) returns (core.user.User) {}
  rpc ListUsers(google.protobuf.Empty) returns (ListUsersResponse) {}
  rpc CreateUser(core.user.User) returns (core.user.User) {}
  rpc UpdateUser(core.user.User) returns (core.user.User) {}
}

message UserRequest {
  string id = 1;
}

message ListUsersResponse{
  repeated core.user.User users = 1;
}

GetUser は非常に簡単です。ID のシンプルな UserRequest メッセージを受け取り、User を返します (コア パッケージから - アプリ内の多くのサービスは User メッセージを入力として受け取るため、共有の場所に配置しています)。 ）。

私の質問は、最適なソリューションが何であるかが不明であるため、Create/Update Users 呼び出しに特に言及しています。2 つの関数は少し異なります。主に、一方のケースでは既にユーザー (つまり ID) があり、もう一方のケースでは新しいユーザーを作成しているという点です。Create の場合、User に存在する可能性のある使用可能なフィールドのサブセットしかない可能性がありますが、このリストはかなり大きくなる可能性があるため、理想的には 1 か所に保持するだけで済みます。次のいずれかが可能です。

  • 呼び出しごとに、カスタムの要求/応答メッセージを定義し、その中に共通のメッセージを埋め込みます。これは、以下のコードのようになります。私の懸念は、基本的に呼び出しごとにメッセージ タイプが存在することになり、保守性の観点からすると非常に面倒なことになる可能性があることです。

コード

message CreateUserRequest{ 
  core.User user = 1;
}
message UpdateUserRequest{
  int32 id = 1;
  core.User user = 2;
}
  • 一般的なメッセージ タイプを期待/送信し、コメントやその他のフィードバック メカニズムに依存して、消費者に正しい値を渡すように促すことができます (私の元の実装が示したもの)。このアプローチに関する私の懸念は、提供されたフィールドが「正しい」ことを確認するために、多くの検証を追加する必要があることです。

他の人がこの種の問題をどのように処理したかについて、オンラインで多くの例を見つけるのに苦労しています。私が提供した例は非常に単純ですが、プロジェクト全体で同様の問題が発生することは想像に難くありません。私が見たいのは、誰かが実際に行ったかなり複雑な gRPC インターフェースの例、またはそれを広く使用した人からのフィードバックで、インターフェース設計のどのパターンが最もうまく機能したかを確認することです。

ありがとう！

4

2 に答える 2