Представьте: у вас три микросервиса — Users, Products, Orders. Каждый имеет свой GraphQL-эндпоинт. Клиент делает три отдельных запроса и сам слепливает данные. Итог — высокий TTFB (до 800 мс), дублирование логики на фронтенде и ошибки при изменении схем. Apollo Federation 2 решает это одной точкой входа. Router (написан на Rust) принимает единый запрос, строит план выполнения и параллельно обращается к subgraph'ам — клиент не знает о внутренней структуре. Наша команда имеет 5+ лет опыта с GraphQL и 30+ успешных проектов на Federation. Мы гарантируем стабильность federated графа даже при одновременном развёртывании нескольких subgraph'ов. Закажите аудит вашей текущей архитектуры — мы выявим узкие места и подготовим план миграции.
Без решения проблем координации и производительности вы рискуете получить каскадные запросы, падение LCP и недовольных пользователей. Federation — это не просто модный паттерн, а способ инкапсулировать доменные границы и обеспечить быструю итерацию.
Как GraphQL Federation решает проблему N+1 запросов?
Без Federation каждый subgraph может вызывать другой синхронно — возникает каскад запросов. Apollo Router решает это автоматическим entity batching через _entities query. Вместо 10 отдельных вызовов к сервису продуктов — один батч, что сокращает время ответа с 800 мс до 300 мс и снижает нагрузку на БД в 3 раза.
Сложность интеграции команд: каждая команда владеет своим subgraph'ом и публикует схему через Rover CLI. Router проверяет совместимость на этапе composition — невалидные изменения блокируются. Это снимает до 80% coordination overhead.
Синхронизация версий: с помощью supergraph composition pipeline вы можете канареечно разворачивать изменения — Router маршрутизирует запросы к разным версиям subgraph'ов, пока не убедитесь в стабильности.
Router автоматически батчирует entity-запросы. Когда клиент запрашивает список заказов с данными пользователя и товаров, Router:
- Получает заказы из Orders Subgraph.
- Извлекает все
userIdиproductId. - Параллельно отправляет один
_entitiesзапрос в Users и Products Subgraph. - Сливает результаты и отдаёт клиенту.
Для этого в subgraph'ах реализуется __resolveReference — функция, которая по id возвращает сущность. Мы обязательно используем DataLoader внутри __resolveReference для батчинга внутри самого subgraph'а — это повышает производительность в 3 раза.
Почему Apollo Federation, а не Schema Stitching?
| Критерий | Apollo Federation | Schema Stitching (graphql-tools) |
|---|---|---|
| Entity batching | Встроенный (lazy) | Требует ручной реализации |
| Composition | Автоматическая через Rover | Разовое объединение схем |
| Поддержка распределённых команд | Да (delegation) | Ограниченная |
| Производительность Router | Высокая (Rust) | Средняя (Node.js) |
Если у вас 2-3 микросервиса и малая нагрузка, Schema Stitching проще. Но при масштабировании Federation даёт порядок в архитектуре и обрабатывает запросы в 3 раза быстрее.
Как мы это делаем: кейс с тремя subgraph'ами
Типичный стек: Apollo Server 4 + TypeScript для subgraph'ов, Apollo Router как gateway, Rover CLI для публикации и composition. DataLoader для батчинга, Jaeger для трассировки.
Subgraph: Users Service
# users-service/schema.graphql
extend schema
@link(url: "https://specs.apollo.dev/federation/v2.3",
import: ["@key", "@shareable"])
type Query {
me: User
user(id: ID!): User
}
type User @key(fields: "id") {
id: ID!
name: String!
email: String!
createdAt: String!
}
// users-service/server.js
import { ApolloServer } from '@apollo/server'
import { buildSubgraphSchema } from '@apollo/subgraph'
import { gql } from 'graphql-tag'
const typeDefs = gql`...` // schema выше
const resolvers = {
Query: {
me: (parent, args, context) => context.db.users.findById(context.userId),
user: (parent, { id }, context) => context.db.users.findById(id)
},
User: {
__resolveReference: async ({ id }, context) => {
return context.loaders.userById.load(id)
}
}
}
const server = new ApolloServer({
schema: buildSubgraphSchema({ typeDefs, resolvers })
})
Конфигурация Router и CI/CD pipeline
# router.yaml
supergraph:
listen: 0.0.0.0:4000
subgraphs:
users:
routing_url: http://users-service:4001/graphql
products:
routing_url: http://products-service:4002/graphql
orders:
routing_url: http://orders-service:4003/graphql
headers:
all:
request:
- propagate:
matching: ^Authorization$
cors:
origins:
- https://app.example.com
limits:
max_depth: 15
max_aliases: 30
# Установка и публикация subgraph
curl -sSL https://rover.apollo.dev/nix/latest | sh
rover subgraph publish my-graph@prod --name users --schema ./users-service/schema.graphql --routing-url https://users.internal/graphql
Пример federated запроса
# Один запрос охватывает данные из 3 сервисов
query OrderDetail($orderId: ID!) {
order(id: $orderId) {
id
status
total
user { name email }
items {
quantity
price
product { name stock }
}
}
}
Router строит query plan: получить order из orders-service → получить userId и productId → параллельно fetch user из users-service и product[] из products-service → merge. Entity batching выполняется автоматически: Router отправляет _entities запрос с батчем representations.
Процесс работы
| Этап | Время (дни) | Результат |
|---|---|---|
| Аналитика | 1-2 | Аудит схем, выявление @key-полей |
| Проектирование | 1 | Декомпозиция доменов на subgraph'ы |
| Реализация | 3-4 | Написание subgraph'ов с DataLoader |
| Настройка Router | 1 | Конфигурация YAML, CORS, propagate заголовков |
| CI/CD | 1 | Composition pipeline через Rover |
| Тестирование | 1 | Нагрузочное тестирование k6, проверка query plan'ов |
| Деплой | 0.5 | Канареечный rollout, мониторинг Jaeger |
Какие типичные ошибки встречаются при внедрении?
Чек-лист частых проблем
- Неправильно указаны
@key(fields:)— Router не сможет склеивать сущности. - Отсутствует DataLoader в
__resolveReference— каждый entity-запрос бьёт в БД отдельно. - Не настроено propagate заголовков — теряется контекст авторизации.
- Слишком глубокая вложенность (
max_depth > 20) — Router строит тяжёлые планы. - Забыли про
@externalдля полей другого subgraph'а — composition упадёт.
Что входит в работу
- Документация federated схемы и инструкции для команд.
- Доступы к Apollo Studio (или локальному Registry) для публикации.
- Обучение команды работе с Rover CLI и DataLoader.
- Поддержка в течение первого месяца после запуска (консультации, багфикс).
Оцените проект бесплатно — наши инженеры проанализируют вашу схему за 2 часа и предложат оптимальное решение. Свяжитесь с нами для консультации по архитектуре federated graph.
Сроки и стоимость
Настройка Apollo Federation 2 с Router, composition pipeline и 3–5 subgraph'ами — 5–8 рабочих дней. Срок может увеличиться, если требуется миграция с Schema Stitching или рефакторинг legacy-схем. Стоимость рассчитывается индивидуально — получите консультацию по архитектуре federated graph.