gRPC
Тема дорожной карты · Backend разработчик
gRPC — высокопроизводительный open-source фреймворк RPC (Remote Procedure Call), разработанный Google, использующий HTTP/2 для транспорта и Protocol Buffers (Protobuf) для сериализации — что делает его стандартным выбором для низкозадержанной, высокопроизводительной коммуникации между микросервисами. Интерфейсы сервисов описываются в .proto-файлах с объявлениями service и rpc; компилятор protoc (с плагином grpc) генерирует типобезопасные клиентские заглушки и базовые классы серверов на Go, Java, Python, Node.js, Rust и других языках, обеспечивая проверку контракта на этапе компиляции через границы сервисов. gRPC поддерживает четыре паттерна коммуникации: унарный RPC (единственный запрос/ответ, как REST), серверная потоковая передача (сервер отправляет поток ответов), клиентская потоковая передача (клиент передаёт поток запросов) и двунаправленная потоковая передача — последние три открывают сценарии использования в реальном времени, недостижимые со стандартным REST. Мультиплексирование HTTP/2 позволяет тысячам параллельных gRPC-вызовов работать через единственное TCP-соединение без блокировки в начале очереди, а встроенные возможности включают распространение дедлайнов, отмену, балансировку нагрузки, взаимную аутентификацию TLS (mTLS) и интерцепторы для логирования, трассировки с OpenTelemetry и валидации JWT. В Kubernetes-окружениях gRPC-сервисы публикуются через Ingress или API-шлюз (Envoy, Nginx, Traefik), обрабатывающий HTTP/2 pass-through или gRPC-Web транскодирование для браузерных клиентов, которые не могут использовать сырое HTTP/2-фреймирование.
Как это работает
gRPC имеет три доминирующих стиля: REST (resource-oriented, использует HTTP-семантику, легко кешируется), GraphQL (клиент выбирает форму, один endpoint, хорошо для разных клиентов), gRPC/RPC (вызов процедур, строгая схема, низкий overhead). Хороший API предсказуем: консистентные имена, версионирован (/v1/users), пагинация для коллекций (курсор лучше offset), фильтруем, идемпотентен где безопасно, задокументирован (OpenAPI для REST, .proto для gRPC, schema для GraphQL).
Когда применять
REST — для публичных API, которые потребляет много третьих сторон: lowest common denominator. GraphQL — когда один backend обслуживает много форм клиента (web + iOS + Android с разными нуждами) и хотите избежать bespoke endpoint на клиента. gRPC — для internal service-to-service, где важны latency + типизированные контракты. Микс ок: публичный REST + internal gRPC — частый кейс.
Типичные ошибки
Ловушки gRPC: нет версионирования ("добавим версию потом" — к тому моменту breaking change для всех); глубоко вложенные ресурсы (/users/123/orders/456/items/789 — плоский лучше); chatty API (клиент делает 10 вызовов на одну страницу — батчите или expand related); утечка внутренних ID (auto-increment integer выдаёт объём — UUID лучше); непоследовательный формат ошибок. Пишите доки API так, будто их прочитает незнакомец.