GraphQL Federation: как масштабировать бэкенд и схему данных

Знакомо чувство, когда ваш монолитный GraphQL-сервер начинает задыхаться? Команда из десяти разработчиков пытается добавить новые фичи в одну огромную схему, а каждый деплой превращается в лотерею. Вы добавляете поле для заказа, ломаете логику пользователя, и весь фронтенд падает. Это классическая боль роста. Но есть способ разделить ответственность и масштабировать GraphQL Federation - это архитектура, которая позволяет разбивать единую графовую схему на независимые подграфы (субграфы), управляемые разными командами. Вместо одного гигантского сервера вы получаете сеть специализированных сервисов, которые вместе создают единое целое для клиента.

Почему обычный REST или монолитный GraphQL не справляются

Давайте будем честны: REST хорош, пока у вас три эндпоинта. Но когда приложение становится сложным, клиенты начинают жаловаться на over-fetching (лишние данные) или under-fetching (недостаточно данных). Они просят один запрос, который вернет профиль, историю заказов, рекомендации и статус доставки. В REST вам пришлось бы делать пять разных запросов и собирать их на клиенте. GraphQL решает эту проблему, давая клиенту власть над данными. Однако, если за этим GraphQL стоит один Node.js-сервер со всей бизнес-логикой компании, вы быстро упретесь в потолок производительности и поддержки кода.

Федерация меняет правила игры. Она позволяет каждому домену (например, «Пользователи», «Заказы», «Продукты») иметь свой собственный GraphQL-сервер. Эти серверы знают только о своих данных. А специальный компонент - GraphQL Gateway (или Router) - собирает все эти куски пазла в единую схему перед отправкой ответа клиенту. Клиент даже не подозревает, что данные пришли из четырех разных микросервисов.

Как работает магия федерации

В основе лежит концепция Subgraph (субграфа). Субграф - это стандартный GraphQL-сервер, который расширяет базовую схему директивами `@key`, `@external` и `@requires`. Допустим, у вас есть тип `User` в сервисе пользователей. Сервис заказов знает, что у пользователя есть ID, но не знает его имя или email. Он объявляет поле `id` как `@external` и ссылается на него через ключ. Когда клиент запрашивает `user { id name orders }`, гейтвей понимает: «Так, имя берет у сервиса A, а заказы - у сервиса B, используя ID как связующее звено».

Этот процесс называется query planning. Гейтвей анализирует входящий запрос, строит план выполнения, параллельно вызывает нужные субграфы и склеивает результаты. Важно понимать, что это происходит динамически. Если клиент не запрашивает заказы, гейтвей вообще не будет дергать сервис заказов. Экономия ресурсов налицо.

Выбор инструментов: Apollo vs Others

На рынке есть несколько реализаций федерации, но безоговорочным лидером является экосистема Apollo Server и Apollo Router. Apollo Router написан на Rust, что дает ему огромное преимущество в скорости обработки запросов по сравнению с JS-решениями. Для продакшена в 2026 году выбор между старым Gateway на Node.js и новым Router на Rust очевиден: берите Router, если вам важна низкая задержка.

Но есть и альтернативы. Например, Hive от The Guild предлагает более легковесный подход и отличную интеграцию с CI/CD для проверки совместимости схем. Или можно рассмотреть Hasura, если вы хотите получить федерацию «из коробки» поверх базы данных, хотя там меньше гибкости в кастомной логике.

Практические шаги для миграции

Не пытайтесь переписать всё сразу. Начните с extraction strangler pattern:

1. Выделите первый домен. Возьмите самый изолированный функционал, например, систему уведомлений.
2. Создайте субграф. Напишите простой GraphQL-сервер, который обслуживает только уведомления. Используйте директиву `@key` для связи с основным типом `User`.
3. Поднимите Gateway. Запустите локально Apollo Router или Hive Gateway и подключите к нему старый монолит и новый субграф.
4. Проверьте суперсхему. Убедитесь, что поля из нового субграфа корректно появляются в общей схеме.
5. Переключайте трафик. Постепенно переводите запросы на новые эндпоинты, следя за метриками ошибок.

Подводные камни и лучшие практики

Первое правило: избегайте циклических зависимостей между субграфами. Если сервис A зависит от B, а B от A, вы получите ад при развертывании и бесконечные рекурсии в query planner. Второе: используйте `@requires` аккуратно. Эта директива говорит: «Чтобы вычислить это поле, мне нужны еще вот эти поля». Если вы потребуете слишком много внешних полей, вы увеличите нагрузку на соседний сервис.

Третье: версионирование схемы критически важно. В федерации нельзя просто так удалить поле, потому что кто-то другой может на него опираться. Инструменты вроде Apollo Studio позволяют проводить автоматические проверки на breaking changes перед деплоем. Не игнорируйте их.

Будущее федерации

Мы видим тренд на усиление безопасности на уровне гейтвея. Теперь можно ограничивать глубину запросов или сложность стоимости (query complexity) прямо на входе, защищая бэкенд от тяжелых DDoS-атак через сложные запросы. Также активно развиваются стандарты вроде Federation v2, где синтаксис стал чище, а поддержка union types и interfaces стала надежнее.