RPC and gRPC contracts

RPC-style API expose **named procedures** с типизированными контрактами — сильный вариант для internal service-to-service, где HTTP resource modeling мало даёт.

**gRPC** использует Protocol Buffers поверх HTTP/2:

					syntax = "proto3";
package orders.v1;

service OrderService {
  rpc GetOrder(GetOrderRequest) returns (Order);
  rpc ListOrders(ListOrdersRequest) returns (stream Order);
  rpc CreateOrder(CreateOrderRequest) returns (Order);
}

message GetOrderRequest { string id = 1; }
message Order { string id = 1; string status = 2; }
				

Возможности:

• **Unary, server streaming, client streaming, bidi streaming**.
• **Deadlines/timeouts** в metadata.
• **Status codes** в `grpc-status` details.
• **Code generation** для многих языков; breaking proto changes требуют дисциплины (field numbers, reserved).

Сравнение с REST: выше performance и строгие контракты; хуже ergonomics в браузере (нужен grpc-web или gateway). Для public HTTP — за API gateway.

На интервью: когда gRPC лучше REST внутри, streaming use cases, правила совместимости protobuf (не переиспользовать field numbers).

Типовые ошибки: breaking proto без version bump, гигантские messages без pagination, нет deadlines, gRPC напрямую в браузер.

Компромисс: скорость разработки в polyglot microservices против human-readable HTTP debugging — grpcurl, reflection, observability.

Чеклист:

• Версионированные proto packages (v1, v2).
• Deadlines на каждый client call.
• Streaming для больших read/write.
• Gateway или BFF для внешних клиентов.