Когда внутри компании десятки сервисов постоянно вызывают друг друга, «просто HTTP API» постепенно перестаёт быть просто. Команды по-разному описывают форматы, версии и ошибки, а несовместимое изменение одного сервиса может неожиданно сломать другой.
gRPC предлагает более строгий контракт: интерфейс описывается заранее, а клиентский и серверный код может генерироваться из одной схемы.
Какую проблему мы решаем
Проблема не в том, что REST медленный или плохой. Проблема появляется, когда сервисов и команд становится много, а цена несовместимых изменений растёт.
gRPC помогает сделать договор между системами явным: какие методы существуют, какие поля передаются и какие типы данных допустимы.
Что получает бизнес
Бизнес получает меньше случайных поломок на стыке команд и более предсказуемую стоимость изменений во внутренних интеграциях.
Когда сервисы развиваются независимо, строгий контракт уменьшает вероятность того, что обновление одного компонента неожиданно остановит другой бизнес-процесс. Это особенно важно там, где много внутренних зависимостей и частые релизы.
Дополнительная ценность — скорость. Команды меньше времени тратят на ручное согласование форматов и больше — на изменения продукта.
Что получает команда
Команда получает типизированный контракт, генерацию клиентов и серверных интерфейсов, эффективную передачу данных и единый способ описывать методы.
Но появляется зависимость от схем, инструментов и дисциплины версионирования. Публичные браузерные API тоже не всегда удобно строить напрямую на gRPC.
Что получает клиент
Внешний клиент чаще всего вообще не знает, что внутри используется gRPC. Его выгода косвенная: меньше интеграционных ошибок, быстрее изменения и более стабильный продукт.
Чем мы за это платим
Цена — дополнительные инструменты, генерация кода, управление схемами и более высокий порог входа для команды.
Если сервисов мало и интеграции простые, строгий контракт может стоить дороже проблем, которые он предотвращает.
Когда gRPC не нужен
Если основная задача — простой публичный API для внешних клиентов, обычный REST часто понятнее и дешевле. Не стоит вводить gRPC только ради производительности, если производительность пока не является ограничением.
Что стоит спросить перед решением
- Сколько команд одновременно меняют связанные сервисы?
- Как часто несовместимые контракты создают инциденты?
- Нужна ли высокая частота внутренних вызовов?
- Готовы ли команды поддерживать схемы и версионирование?
В итоге
gRPC полезен не потому, что он «современнее REST», а когда стоимость неявных внутренних контрактов уже стала заметной для бизнеса.