Структуры сообщений GRPC - PullRequest
Новая
       44

Структуры сообщений GRPC

1 голос
/ 08 мая 2019

Я нахожусь в процессе миграции унаследованного приложения (немного микросервисов и монолита) на использование GRPC. Вся база кода в настоящее время в GO.

Я начал моделировать свои сообщения, и они выглядят очень похоже на мои структуры, которые я использую в своем коде приложения. Кажется странным, что у меня одни и те же объекты определены дважды, но также странно использовать объекты сообщений в качестве структур ядра. Похоже, у меня будет много интенсивного маршалинга данных. Ниже приведен пример сообщения и структуры, а также их сходство.

Существуют ли какие-либо рекомендации / лучшие практики для принятия решения о том, как моделировать мои сообщения? Должны ли они быть согласованы с моими основными структурами? Разве я не должен заботиться обо всех сортировках, которые должны происходить из моих структур Голанга в сообщения?

Простите, если я задаю такой базовый вопрос, поскольку я очень плохо знаком с буферами протокола и GRPC.

Сообщение Proto Def: 

message Profile {
    string UID = 1;
    string ContactEmail = 2;
    google.protobuf.Timestamp DateOfBirth = 3;
    float WeightInKilos = 4;
    string Gender = 5;
    string Unit = 6;
    string CurrentStatus = 7;
    string Country = 8;
    string ExperienceType = 9;
    google.protobuf.Timestamp DateJoined = 10;
    repeated Ability Abilities = 11;
    repeated Role Roles = 12;
    repeated TermsAndConditionsAcceptance TermsAndConditionsAcceptances = 13;
    string TimeZone = 14;
    repeated BaselineTestResults BaselineTests =15;
    //Excluded UpdatedDate as other domains shouldn't need it
    string FirstName =16;
    string LastName =17;
    string DisplayName = 18;
    string State = 19;
    repeated google.protobuf.Any Preferences = 20;
    Thresholds Thresholds = 21;
    string StripeCustomerID = 22;
}

Struct Def: 

type Profile struct {
    UID                           string                         `json:"UID" firestore:"UID"`
    ContactEmail                  string                         `json:"ContactEmail,omitempty" firestore:"ContactEmail"`
    DateOfBirth                   time.Time                      `json:"DateOfBirth,omitempty" firestore:"DateOfBirth"`
    WeightInKilos                 float64                        `json:"WeightInKilos,omitempty" firestore:"WeightInKilos"`
    Gender                        string                         `json:"Gender,omitempty" firestore:"Gender"`
    Unit                          string                         `json:"Unit,omitempty" firestore:"Unit"`
    CurrentStatus                 string                         `json:"CurrentStatus,omitempty" firestore:"CurrentStatus"`
    Country                       string                         `json:"Country,omitempty" firestore:"Country"`
    ExperienceType                string                         `json:"ExperienceType,omitempty" firestore:"ExperienceType"`
    DateJoined                    time.Time                      `json:"DateJoined,omitempty" firestore:"DateJoined"`
    Abilities                     []Ability                      `json:"Abilities,omitempty" firestore:"Abilities"`
    Goals                         Goals                          `json:"Goals,omitempty" firestore:"Goals"`
    Roles                         []Role                         `json:"Roles,omitempty" firestore:"Roles"`
    TermsAndConditionsAcceptances []TermsAndConditionsAcceptance `json:"TermsAndConditionsAcceptances,omitempty" firestore:"TermsAndConditionsAcceptances"`
    TimeZone                      string                         `json:"TimeZone,omitempty" firestore:"TimeZone"`
    BaselineTests                 []BaselineTestResults          `json:"BaselineTests,omitempty" firestore:"BaselineTests"`
    UpdatedDate                   time.Time                      `json:"UpdatedDate,omitempty" firestore:"UpdatedDate"`
    FirstName                     *string                        `json:"FirstName,omitempty" firestore:"FirstName"`
    LastName                      string                         `json:"LastName,omitempty" firestore:"LastName"`
    DisplayName                   string                         `json:"DisplayName,omitempty" firestore:"DisplayName"`
    State                         string                         `json:"State"`
    Preferences                   map[string]interface{}         `json:"Preferences"`
    Thresholds                    Thresholds                     `json:"Thresholds"`
    StripeCustomerID              string                         `json:"-"` //Tells it to ignore exporting
}

Ответы [ 2 ]

1 голос
/ 08 мая 2019

Хотя это очень простой вопрос, но и очень хороший вопрос.Люди обычно пропускают его, и ему приходится бороться с базой кода позже, когда она растет.

Конечно, использование сообщения в качестве структур ядра будет полезно в тех случаях, когда данные, необходимые для обработки запроса, полностью доступны в сообщении.Но в случаях, когда вам нужно получить данные из других источников, это не поможет.

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

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

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

0 голосов
/ 08 мая 2019

вам не нужно создавать структуры в коде приложения. просто используйте сообщения прото файла. Вот быстрый старт GRPC в Go.

https://grpc.io/docs/quickstart/go/

...