Мобильному приложению для экрана заказа нужны статус, сумма и дата доставки. Веб-кабинет хочет ещё историю изменений, скидки и данные по возвратам. Разработчики API предлагают один большой ответ на все случаи. А клиентские команды просят не передавать лишние данные и перестать ждать каждой новой комбинации полей.
Обычно в этот момент возникает разговор о GraphQL. Он действительно позволяет клиенту описать, какие данные нужны для запроса. Но проблема, которую стоит решать, не в отсутствии GraphQL. Она в том, сколько времени и денег компания тратит на согласование изменений между клиентами и сервером.
Разные способы договориться об ответе
В привычном REST API сервер публикует ресурсы и операции. Условно: получить заказ по идентификатору, получить список заказов, изменить адрес доставки. Форму ответа и правила операции команда проектирует заранее. При необходимости она может предложить разные представления, фильтры и параметры — REST не запрещает делать удобные API.
GraphQL описывает доступные типы и поля как схему. Клиент сам формирует выборку: у заказа нужны сумма, статус и только имя получателя. Если данные лежат в нескольких внутренних системах, сервер GraphQL может собрать их через резолверы.
Нельзя назвать первый вариант негибким, а второй свободным от договорённостей. У GraphQL тоже есть контракт. Просто гибкость выбора ответа становится частью этого контракта, а число допустимых комбинаций увеличивается.
Когда эта свобода экономит время
Допустим, у продукта несколько активно развивающихся интерфейсов. Каждый экран нуждается в своей комбинации данных, и команда API регулярно превращается в очередь заявок на небольшие изменения. Тогда GraphQL может сократить часть согласований: клиент выбирает уже опубликованные поля без нового endpoint.
Но если задержка связана не с формой ответа, а с бизнес-правилом — например, можно ли вернуть оплаченный заказ, — GraphQL её не устранит. Такое правило всё равно должен определить и реализовать владелец соответствующей функции.
Для простого партнёрского API часто выигрывает предсказуемость REST: понятные операции, явная документация, более привычные инструменты HTTP-кеширования. Если интеграция годами запрашивает несколько стабильных ресурсов, свобода комбинировать произвольные поля может вообще не понадобиться.
Кто заплатит за «получить всё за один запрос»
Один сетевой запрос от клиента не означает одну дешёвую операцию сервера. В GraphQL простой на вид запрос может обойти множество связей и вызвать десятки обращений к внутренним системам. Нужны ограничения глубины и стоимости, контроль объёма выдачи, защита от неудачных резолверов и наблюдаемость на уровне операций.
В REST сложные цепочки тоже возможны, особенно если клиент самостоятельно собирает экран из множества вызовов. Но у конкретного endpoint стоимость часто проще оценить и ограничить. При одинаковых требованиях к скорости разумнее сначала измерить реальные задержки, чем выбирать технологию по числу запросов на диаграмме.
С безопасностью ситуация ещё интереснее. В GraphQL клиент может попросить поля, которые не должны быть ему доступны. Проверять только вход в общий endpoint недостаточно: права на конкретный заказ и его данные должны обеспечиваться в бизнес-логике, независимо от формы запроса. Официальная документация GraphQL по авторизации прямо подчёркивает это разделение.
Что я бы проверил перед решением
Попросил бы взять несколько реальных экранов и партнёрских сценариев: какие данные им нужны, где возникают лишние запросы, как часто команды ждут изменения контракта и кто сегодня отвечает за формирование ответа.
Если главная проблема — число обращений к внутренним сервисам, альтернативой может быть API Composition или Backend for Frontend. Эти решения тоже позволяют собрать ответ на сервере, не открывая клиентам произвольный граф данных.
И ещё один вопрос: кто будет управлять сложностью запросов, публичной схемой и устаревшими полями через несколько лет? Гибкость должна иметь владельца.
Я бы выбирал GraphQL не за красивую возможность запросить произвольные поля, а за уменьшение реального трения между клиентскими и серверными командами. Если такого трения нет, простой REST вполне может быть лучшей архитектурой.