Представьте: у вас 30 микросервисов, каждый со своим API. Клиенты — веб, мобильные приложения, партнёры — вынуждены делать десятки запросов, чтобы собрать одну страницу. Разработка замедляется, а количество багов растёт. Знакомо? Именно здесь на помощь приходит GraphQL Federation и API Gateway. В этой статье разберём реальный сценарий объединения микросервисов в единый граф, покажем подводные камни и объясним, как не утонуть в схеме.
Ситуация: 30 микросервисов и один уставший фронтенд
Типичная картина: интернет-магазин вырос, бэкенд разбили на отдельные сервисы — каталог, корзина, заказы, платежи, рекомендации. Каждый предоставляет REST API. Фронтенд для отображения карточки товара с рекомендациями и наличием на складе делает 5–7 запросов к разным эндпоинтам. Мобильное приложение страдает от задержек, а команда тратит недели на согласование контрактов.
GraphQL Federation решает это, позволяя описать каждый микросервис как subgraph (подграф) с частью общей схемы. Затем API Gateway (например, Apollo Router) объединяет их в supergraph — единый граф, который клиенты запрашивают одним запросом. Шлюз сам решает, какие подграфы вызвать и как собрать ответ.
Как это работает на практике: шаг за шагом
Возьмём тот же магазин. Допустим, есть сервис products и сервис reviews. В Apollo Federation каждый определяет свою часть схемы. Сервис products объявляет тип Product с полями id, name, price. Сервис reviews расширяет этот тип, добавляя поле reviews. Чтобы связать их, используется директива @key — она указывает, что тип Product идентифицируется по полю id. Вот как это выглядит в схеме products:
type Product @key(fields: "id") {
id: ID!
name: String!
price: Float!
}
А в схеме reviews:
extend type Product @key(fields: "id") {
id: ID! @external
reviews: [Review!]!
}
type Review {
id: ID!
text: String!
rating: Int!
}
Теперь клиент может запросить товар с отзывами одним запросом:
query {
product(id: "123") {
name
price
reviews {
text
rating
}
}
}
Шлюз (Apollo Router) разберёт этот запрос, обратится к сервису products за именем и ценой, а к reviews — за отзывами, и склеит результат. Всё это происходит автоматически, без участия клиента.
Что важно знать: Apollo Federation v2 (актуальная на 2026 год) использует директивы @shareable, @inaccessible, @override для управления общими полями и миграциями. Например, @shareable позволяет нескольким подграфам возвращать одно и то же поле, а @override — постепенно переносить поле из одного сервиса в другой.
Где чаще всего спотыкаются
-
N+1 проблема. Когда шлюз запрашивает отзывы для списка товаров, он может сделать отдельный запрос к
reviewsдля каждого товара. Это убивает производительность. Решение — DataLoader: батчинг и кеширование запросов внутри подграфа. Без него federation может превратиться в узкое место. -
Сложные запросы без ограничений. Клиент может запросить слишком глубокую вложенность или огромное количество полей, что приведёт к перегрузке. Обязательно настраивайте query depth limiting и rate limiting на уровне шлюза.
-
Неверное определение сущностей. Если
@keyуказан неправильно или поле-идентификатор не уникально, шлюз не сможет правильно собрать данные. Это приводит к ошибкам в рантайме, которые сложно отловить. -
Отсутствие мониторинга. Без трассировки запросов через шлюз вы не увидите, какой подграф тормозит. Используйте Apollo Studio или Grafbase для observability.
Альтернативы: GraphQL Mesh и Hasura
Apollo Federation — не единственный путь. GraphQL Mesh позволяет объединить существующие REST, gRPC и другие API в единый GraphQL-шлюз без переписывания сервисов. Это быстрый старт, но меньше контроля над схемой. Hasura даёт мгновенный GraphQL поверх PostgreSQL с готовой федерацией, но привязывает к своей экосистеме.
Выбор зависит от задачи: если у вас уже есть GraphQL-сервисы и нужна гибкая федерация — Apollo. Если нужно быстро поднять шлюз над разнородными API — Mesh. Если данные в PostgreSQL и нужна скорость — Hasura.
Как освоить федерацию на практике
Самостоятельное изучение GraphQL Federation упирается в три барьера: отсутствие обратной связи (некому указать на ошибки в схеме), разрозненность информации (директивы меняются от версии к версии) и дорогие ошибки в продакшене. Курсы дают структуру и разбор кейсов, но требуют времени и денег. Практика на пет-проекте — бесплатно, но без ментора легко уйти в тупик.
Если вы хотите пройти путь от основ GraphQL до построения федеративного API из нескольких микросервисов с разбором реальных сценариев и обратной связью, обратите внимание на курс GraphQL Federation и API Gateway. Там вы соберёте работающий supergraph, настроите шлюз и научитесь избегать типичных ошибок.
Кому подойдёт: бэкенд-разработчикам, архитекторам и тимлидам, знакомым с GraphQL или REST и желающим перейти на федеративную архитектуру. Если вы только начинаете путь в API, сначала стоит освоить базовый GraphQL — иначе федерация покажется магией.