Введение в RPC и gRPC

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

gRPC не делает сеть простой. Он делает договор между сервисами явным. Вы всё равно будете думать про таймауты, обратную совместимость, ретраи, нагрузку и диагностику, но будете делать это не через набор неформальных JSON-описаний, а через .proto-контракты и единый runtime.

Что будет внутри

В модуле разберём, чем RPC отличается от REST, как устроены Protocol Buffers, как писать gRPC server и client на Go, как передавать context, deadlines и metadata, как маппить ошибки, где место gRPC в Clean Architecture и когда streaming действительно нужен.

К концу модуля у вас должна сложиться такая схема:

Как понять, что освоил

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

Рабочие ориентиры

• Контракт должен быть стабильнее реализации. .proto меняется осторожнее, чем Go-код за ним.
• Deadline без обработки ошибки почти бесполезен. Сервис должен не только принять context, но и уважать его.
• gRPC хорош для service-to-service, но не обязан заменять REST везде. Выбор транспорта должен вытекать из сценария, а не из моды.