Ответ
gRPC-Gateway — это плагин для protoc (компилятора Protocol Buffers), который читает описание gRPC-сервиса и генерирует обратный прокси-сервер. Этот прокси-сервер преобразует RESTful JSON API запросы в gRPC вызовы.
Назначение:
Основная цель — предоставить единый API как для современных клиентов, использующих gRPC, так и для legacy-систем или браузеров, которые могут работать только с REST/JSON.
Как это работает:
Вы добавляете специальные аннотации google.api.http в ваш .proto файл, описывая, как HTTP-запросы должны мапиться на gRPC-методы.
// service.proto
import "google/api/annotations.proto";
service YourService {
rpc GetEntity(GetEntityRequest) returns (Entity) {
option (google.api.http) = {
get: "/v1/entities/{id}"
};
}
}После генерации кода вы получаете HTTP-обработчик, который можно запустить на отдельном порту. Он будет принимать HTTP-запросы (например, GET /v1/entities/123), преобразовывать их в gRPC-сообщения и вызывать ваш основной gRPC-сервис.
Плюсы:
- Единый источник правды: Описание API (и для gRPC, и для REST) находится в одном
.protoфайле. - Автогенерация: Генерирует не только прокси, но и OpenAPI (Swagger) спецификацию для вашего REST API, что упрощает документирование.
- Экономия времени: Не нужно вручную писать отдельный REST-слой и логику преобразования данных.
- Постепенная миграция: Позволяет существующим REST-клиентам работать с новой системой на gRPC.
Минусы:
- Дополнительный слой: Прокси — это еще один сетевой хоп и дополнительная операция (un)marshalling JSON ↔ Protobuf, что добавляет задержку и потребляет ресурсы.
- Ограниченная гибкость: Сложно реализовать кастомную логику (например, сложную аутентификацию, middleware) на уровне самого гейтвея. Обычно это выносится на уровень выше (например, в API Gateway).
- Усложнение сборки: В CI/CD пайплайн добавляется еще один шаг кодогенерации.