Для нового внутреннего сервиса с высокой нагрузкой команда выбирает между REST, GraphQL и gRPC. Как подойти к этому выбору? Обсудите компромиссы, риски и критерии выбора — единственного правильного решения может не быть.?

Короткий ответ

Выбор зависит от состава клиентов (браузер/мобильный клиент против внутреннего сервиса), требований к производительности и строгой типизации контракта, а не от того, какой подход считается "современнее"; REST проще для внешних и разнородных клиентов, GraphQL — когда клиентам нужна гибкая форма ответа, gRPC — для внутренних высоконагруженных сервис-сервис взаимодействий с строгим контрактом и минимальными накладными расходами.

Как это работает подробнее

REST поверх HTTP/1.1 или HTTP/2 с JSON — универсален, легко отлаживается curl'ом/браузером, широко поддержан инструментами; GraphQL даёт клиенту контроль над формой ответа через единый эндпоинт, но требует продуманного батчинга резолверов и защиты от дорогих запросов; gRPC поверх HTTP/2 с Protobuf даёт компактную бинарную сериализацию, строгую типизацию по .proto-схеме, встроенную поддержку стриминга, но хуже отлаживается вручную (нужны специальные инструменты вместо curl) и менее дружелюбен к браузерным клиентам без дополнительного прокси (grpc-web).

Пример кода

example.txtКопировать

// orders.proto — пример контракта gRPC для внутреннего сервиса
syntax = "proto3";
service OrdersService {
  rpc GetOrder (GetOrderRequest) returns (Order);
}
message GetOrderRequest {
  int64 order_id = 1;
}
message Order {
  int64 id = 1;
  string status = 2;
  double total = 3;
}

Что использовать на практике

• Рекомендация. для внутреннего высоконагруженного сервис-сервис взаимодействия gRPC часто даёт заметный выигрыш в задержке и объёме трафика за счёт бинарной сериализации и мультиплексирования HTTP/2, но накладывает инфраструктурные требования (генерация кода из .proto, поддержка версии схемы, инструменты наблюдаемости, адаптированные под gRPC). Если команда без опыта с gRPC внедряет его "потому что он быстрее", риски операционной сложности и кривой обучения могут превысить выгоду, особенно если реальная нагрузка далека от узкого места производительности. Компромисс: gRPC даёт производительность и строгую типизацию, но стоит дороже в операционной сложности, обучении команды и интеграции с браузерными/внешними клиентами; REST даёт простоту, универсальность и низкий порог входа, но менее эффективен по трафику/CPU на сериализацию при очень высокой нагрузке; GraphQL решает проблему гибкости формы ответа для разнородных клиентов, но добавляет сложность на сервере (батчинг, защита от дорогих запросов) и не имеет смысла там, где форма ответа фиксирована. Критерии выбора: реальный профиль нагрузки и узкое место, состав клиентов (внутренние/внешние, браузер/сервис), готовность команды поддерживать выбранную технологию, и то, насколько критична задержка/трафик именно на уровне сериализации протокола, а не в другом месте системы.

Подводные камни

• Риски. выбирать gRPC только из соображений "производительности" без фактического профилирования, где реально узкое место (часто бутылочное горлышко — не сериализация, а БД или внешние зависимости); внедрять GraphQL для внутреннего сервис-сервис API, где нужен фиксированный простой контракт, а не гибкая форма ответа для разнородных UI-клиентов — это добавляет сложность без соответствующей выгоды.