grpc Protobuff 3 определения вложенных сообщений - PullRequest
Новая
       6

grpc Protobuff 3 определения вложенных сообщений

0 голосов
/ 13 февраля 2019

Я бы хотел определить свои сообщения во вложенном виде следующим образом:

FooRequest

  • messageId
  • correlationId
  • moreFields
  • payload (выделенный прото, содержащий полезную нагрузку Foo)

И используйте запросы в моих определениях службы grpc, например: 

service SessionManager {
    rpc CreateSession (CreateSessionRequest) returns (CreateSessionResponse) {}
    rpc DropSession (DropSessionRequest) returns (DropSessionResponse) {}
}

Для этого было бы неплохоопределите Request прото только один раз и повторно используйте его для всех запросов, которые я хочу создать. 

message Request {
    string messageId = 1;
    string origin = 2;
    string correlationId = 3;
    int32 sentAt = 4;
    string type = 5;
    int32 version = 6;
    google.protobuf.Any metadata = 7;
    google.protobuf.Any payload = 8;
}

Вместо этого: 

message CreateSessionRequest {
    string messageId = 1;
    string origin = 2;
    string correlationId = 3;
    int32 sentAt = 4;
    string type = 5;
    int32 version = 6;
    google.protobuf.Any metadata = 7;
    CreateSessionPayload payload = 8;
}

message DropSessionRequest {
    string messageId = 1;
    string origin = 2;
    string correlationId = 3;
    int32 sentAt = 4;
    string type = 5;
    int32 version = 6;
    google.protobuf.Any metadata = 7;
    DropSessionPayload payload = 8;
}

Возможно ли это как-то?

1 Ответ

0 голосов
/ 13 февраля 2019

Это определенно возможно, хотя есть и другие способы сделать это.Вы можете выделить общие поля в одно сообщение, которое включено в каждый из ваших запросов / ответов: 

message CommonRequestFields {
  string messageId = 1;
  string origin = 2;
  string correlationId = 3;
  int32 sentAt = 4;
  string type = 5;
  int32 version = 6;
}

Вы можете включить это как формальное поле для каждого типа сообщения запроса, без необходимости зависеть отAny: 

message CreateSessionRequest {
  CommonRequestFields common = 1;
  Session session = 2;
  // ...
}

message DropSessionRequest {
  CommonRequestFields common = 1;
  string sessionId = 2;
  // ...
}

Этот подход имеет несколько преимуществ:

  • Легко добавлять общие поля для каждого запроса
  • Вы можете обрабатывать каждый запрос общими полямиодинаково на клиенте и сервере
  • Идентификаторы и имена полей не влияют на идентификаторы и имена полей, специфичные для запроса

Однако есть некоторые недостатки:

  • Вам нужно проверить наличие общих полей, а не прямой доступ к полю
  • Для некоторых запросов могут не понадобиться все общие поля, что приводит к увеличению числа сообщений
  • Что общегосегодня не может быть обычным явлением через 6 месяцев, так как требования меняются.

Наконец, если вы используете gRPC, вы можете отправлять метаданные вместе с каждым запросом, который находится за пределами тела запроса.Поля метаданных представляют собой пары ключ-значение String (такие же, как заголовки HTTP) и могут подходить, если вы отправляете их для каждого запроса или ответа.Вы даже можете кодировать прототипы как поля заголовка, хотя для этого может потребоваться более сложное использование API.

...