Инженерные команды до сих пор тратят целые дни на споры о том, мертв ли REST или gRPC сделал всё остальное устаревшим. Этот спор упускает главное. Вы выбираете не «лучший» протокол. Вы выбираете правильную границу. Протокол, который идеально работает внутри вашего кластера Kubernetes, «задохнется», когда вы отдадите его тысяче внешних разработчиков. Протокол, который экономит драгоценную пропускную способность вашего мобильного приложения, обанкротит вашу инфраструктуру, если вы откроете его для произвольных публичных запросов. Если относиться к этому решению как к конкурсу популярности технологий, вы создадите архитектурный долг, который переживет каждого текущего участника вашей команды.
Принцип границы
Архитектура — это поиск компромиссов, а не выбор чемпионов. Правильный вопрос никогда не звучит как «Какой быстрее?» или «Какой новее?». Он звучит так: «Кто находится на другом конце провода и что он контролирует?». Протоколы — это объекты границы. Выбор неверного протокола не просто замедлит вас. Он на годы закрепит ошибки в вашей системе.
Публичные API: REST — это не скучно, это ответственно
Когда вашим потребителем является внешний разработчик, которого вы никогда не видели, ваш API становится продуктом, а не просто интерфейсом. Этот разработчик занимается отладкой в два часа ночи, имея под рукой только curl и коллекцию Postman. Если ему придется устанавливать кастомную клиентскую библиотеку или изучать язык схем перед первым успешным вызовом, вы его уже потеряли.
REST выживает здесь потому, что он и есть сам веб. Методы HTTP, коды состояния и JSON — это общий язык. Кэширование здесь не является второстепенной задачей; это уже существующая инфраструктура. Браузеры, CDN и граничные кэши (edge caches) нативно понимают заголовки Cache-Control и валидацию ETag. Вы можете разместить REST API за стандартным CDN и мгновенно сэкономить на трафике, не написав ни единой строки логики кэширования. Это имеет значение, когда публичный трафик непредсказуем, а вы платите за каждый гигабайт, покидающий ваше облако.
GraphQL, напротив, накладывает высокие накладные расходы на публичную границу. Публичные эндпоинты GraphQL требуют анализа стоимости запросов (query cost analysis), ограничения глубины (depth limiting) и оценки сложности (complexity scoring), чтобы один неосторожный или вредоносный запрос не обрушил вашу базу данных. Вы не просто поставляете API; вы строите движок выполнения запросов, стратегию ограничения частоты запросов (rate-limiting) и модель тарификации вычислений. Если у вас нет операционных мощностей крупнейших платформ, такие расходы неоправданны для публичной поверхности. REST устанавливает защитные барьеры по умолчанию. Каждый эндпоинт делает одну вещь. Потребители получают именно то, что вы предлагаете, а не то, что им вздумается.
Внутренние сервисы: контролируйте весь канал
Внутри вашей организации разговор меняется. Вы контролируете и клиент, и сервер. Вы можете диктовать технологический стек для каждого сервиса в цепочке вызовов. Именно здесь gRPC оправдывает свое существование.
Во-первых, перестаньте относиться к JSON как к священному писанию. Protocol Buffers сериализуют данные примерно в три раза быстрее, чем JSON. Полезная нагрузка (payload) меньше, потому что формат бинарный. В загруженной внутренней сети эти миллисекунды и мегабайты превращаются в реальные деньги и снижение хвостовой задержки (tail latency). Что еще важнее, Protobuf дает вам строгий контракт. Когда вы меняете тип поля или переименовываете сообщение, ошибка происходит на этапе компиляции, а не в три часа ночи в продакшене, когда нижестоящий сервис начинает выбрасывать исключения парсинга.
gRPC работает поверх HTTP/2, поэтому вы получаете сжатие заголовков, мультиплексирование потоков и полноценную семантику стриминга. Если вы передаете высоконагруженные события между сервисами или отправляете обновления в реальном времени, серверный и двунаправленный стриминг являются нативными функциями, а не костылями в виде long-polling, приклеенными к фреймворку запрос-ответ.
Есть один важный нюанс: не направляйте gRPC напрямую в браузер. Модели сетевого взаимодействия браузеров не работают с HTTP/2 так, как того ожидает gRPC. Вам придется «приживлять» grpc-web и прокси вроде Envoy к вашему стеку только для того, чтобы браузер смог поговорить с бэкендом. Это не баг, это сигнал о границе. Держите gRPC за своим файрволом, между сервисами, которые доверяют друг другу, и воспринимайте сложность его отладки как цену за скорость. Бинарную полезную нагрузку не так удобно просматривать глазами в лог-файле, как JSON.
Сложные интерфейсы и мобильные устройства: ниша GraphQL
Современные мобильные экраны — это лоскутное одеяло. Одному представлению может понадобиться профиль пользователя,