awesome-everything EN
↑ Обратно к восхождению

API

gRPC и Protobuf: чтение схемы и proto

Суть Читай реальные .proto-сниппеты — правки field tag, reserved, сигнатуры streaming — и предсказывай поведение на проводе или фикс с наибольшим рычагом.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбите
◷ 14 min

Схема Protobuf — это контракт, который ты читаешь на код-ревью, до того как порча уедет в прод. Прочитай каждый diff или сигнатуру, разберись, что это делает на проводе, и выбери изменение, которое senior реально одобрил бы.

Цель

Потренируй ревью, которое ты прогоняешь на каждом proto-PR: замечай ловушки field tag, подтверждай, что удаление корректно reserved, и читай сигнатуру streaming на ту форму вызова, которую она реально объявляет.

Сниппет 1 — diff field tag

 message Order {
   string id = 1;
   int64 amount_cents = 2;
-  int32 discount_pct = 3;
-  Priority priority = 4;
+  Priority priority = 3;
+  Coupon coupon = 4;
 }
Викторина

Старый клиент записал Order с priority в поле 4. Сервис, задеплоенный с этой новой схемой, читает то сообщение. Что он видит и почему?

Сниппет 2 — удаление

message Customer {
  reserved 2, 5 to 7;
  reserved "email", "legacy_tier";
  string id = 1;
  string display_name = 3;
  Address address = 8;
}
Викторина

Предложено новое поле: вернуть `string email = 2;`, потому что команда снова хочет email. Это компилируется и это правильный ход?

Сниппет 3 — сигнатуры streaming

service ChatService {
  rpc History(HistoryRequest) returns (stream Message);
  rpc Send(stream Message) returns (SendSummaryResponse);
  rpc Live(stream Message) returns (stream Message);
}
Викторина

Сопоставь каждый RPC с его формой вызова и положением ключевого слова stream.

Сниппет 4 — presence в proto3

message UpdateProfile {
  string user_id = 1;
  string bio = 2;            // обычный скаляр
  optional bool marketing_opt_in = 3;  // явное presence
}
Викторина

Клиент шлёт UpdateProfile с bio равным пустой строке и опущенным marketing_opt_in. Сервер хочет сделать PATCH только тех полей, которые клиент реально намеревался изменить. Что схема даёт ему различить?

Итог

Ревью Protobuf — это чтение номеров, а не имён: diff с перенумерацией молча направляет старые значения в неверное поле, поэтому эволюция должна быть append-only с reserved, охраняющим удаления (а protoc принуждает резервацию). Сигнатуру streaming читают по тому, какая сторона несёт stream — запрос для client, ответ для server, обе для bidi. А presence в proto3 реален, но opt-in: обычные скаляры не отличают unset от default, поэтому PATCH-стиль API тянется к optional или FieldMask. Лови это на ревью, до того как порча задеплоится.

Продолжить восхождение ↑gRPC и Protobuf: построй контракт, переживающий эволюцию
хоткеи развернуть
поиск
K
пред. пьеса
k
след. пьеса
j
тиры
t
это меню
?
sources2
expand
  1. 01
  2. 02

Trademarks belong to their respective owners. Editorial reference only.