Представьте: фронтенд-команда тратит часы на координацию с бэкендерами, чтобы собрать одну страницу. Каждый микросервис отдаёт данные в своём формате — приходится делать 5–10 запросов к разным API. Возникают N+1 проблемы, latency растёт, кэширование превращается в головную боль. На одном из проектов мы сократили количество запросов с 12 до 2, внедрив Federation. Наш опыт — 7+ лет в распределённых системах, более 50 продакшен-внедрений GraphQL. Федерация — это не просто gateway, а декларативный подход: каждая команда описывает, как её микросервис расширяет общий граф данных. В отличие от ручного агрегирования, Federation автоматически строит оптимальный план выполнения, используя @key и @requires.
Как объединить микросервисы с помощью GraphQL Federation?
Federation позволяет объединить несколько независимых GraphQL-сервисов (subgraph) в единый API. Клиент делает один запрос к Federation Gateway (Apollo Router), который собирает данные из разных subgraph и возвращает единый ответ. Каждая команда владеет своим subgraph и деплоит его независимо — без блокировок и согласований. Apollo Federation specification описывает все детали протокола.
Архитектура Federation:
- Клиент (браузер/мобильное) → Federation Gateway (Apollo Router / Apollo Gateway)
- User Subgraph (Node.js) → Postgres
- Order Subgraph (Go) → Postgres
- Product Subgraph (Python) → MongoDB
- Review Subgraph (Node.js) → Postgres
Subgraph: User Service — пример реализации
// user-service/schema.ts import { buildSubgraphSchema } from '@apollo/subgraph'; import { gql } from 'graphql-tag'; const typeDefs = gql` extend schema @link(url: "https://specs.apollo.dev/federation/v2.3", import: ["@key", "@shareable"]) type User @key(fields: "id") { id: ID! name: String! email: String! createdAt: DateTime! } type Query { me: User user(id: ID!): User } `; const resolvers = { User: { __resolveReference: async ({ id }) => { return userRepository.findById(id); } }, Query: { me: (_, __, { userId }) => userRepository.findById(userId), user: (_, { id }) => userRepository.findById(id) } }; export const schema = buildSubgraphSchema({ typeDefs, resolvers });Subgraph: Order Service — расширение типов
// order-service/schema.ts const typeDefs = gql` extend schema @link(url: "https://specs.apollo.dev/federation/v2.3", import: ["@key", "@external", "@requires"]) type Order @key(fields: "id") { id: ID! status: OrderStatus! total: Float! items: [OrderItem!]! customer: User! createdAt: DateTime! } type User @key(fields: "id") { id: ID! @external orders(limit: Int = 10): [Order!]! orderStats: OrderStats! } type OrderStats { totalOrders: Int! totalSpent: Float! lastOrderAt: DateTime } enum OrderStatus { PENDING PAID SHIPPED DELIVERED CANCELLED } type Query { order(id: ID!): Order orders(customerId: ID, status: OrderStatus): [Order!]! } `; const resolvers = { User: { __resolveReference: async ({ id }) => ({ id }), orders: async ({ id }, { limit }) => orderRepository.findByCustomerId(id, limit), orderStats: async ({ id }) => orderRepository.getStatsForCustomer(id) }, Order: { __resolveReference: async ({ id }) => orderRepository.findById(id), customer: ({ customerId }) => ({ __typename: 'User', id: customerId }) } };Apollo Router (Federation Gateway) — конфигурация
# router.yaml federation_version: 2.3 supergraph: listen: 0.0.0.0:4000 subgraphs: users: routing_url: http://user-service:4001/graphql orders: routing_url: http://order-service:4002/graphql products: routing_url: http://product-service:4003/graphql cors: origins: - https://app.example.com headers: all: request: - propagate: named: Authorization - propagate: named: X-Correlation-IdЗапуск через Docker:
docker run -p 4000:4000 -v $(pwd)/router.yaml:/dist/config/router.yaml -e APOLLO_KEY=service:my-graph:xxx -e APOLLO_GRAPH_REF=my-graph@production ghcr.io/apollographql/router:latest.Что даёт Federation по сравнению с REST и обычным Gateway?
Характеристика Federation REST-агрегатор Обычный Gateway Количество запросов 1 5–10 1 (но данные собираются последовательно) Время ответа ~50 мс (параллельные запросы) ~200 мс ~100–150 мс (последовательно) Независимость команд ✅ Каждая команда владеет subgraph ❌ Общая кодовая база ❌ Общая кодовая база Изменение схемы Без блокировок Согласование Согласование Кэширование На уровне subgraph HTTP-кэш Централизованное Federation позволяет повысить производительность в 2–3 раза по сравнению с REST-агрегатором за счёт параллельной выборки и кэширования на уровне subgraph. На одном проекте мы снизили время загрузки страницы с 2.3 до 0.8 секунды.
Инструмент Назначение Распространение Apollo Router Federation Gateway, параллельный сбор данных Open source + Managed Apollo Rover CLI Публикация и проверка схем Open source Apollo Studio Реестр схем, мониторинг SaaS Managed Federation (Apollo Studio)
При Managed Federation схемы subgraph публикуются в Apollo Studio Registry. Router загружает актуальную supergraph-схему автоматически при изменении любого subgraph. Публикация с проверкой совместимости выполняется через
rover subgraph check.# В CI/CD пайплайне rover subgraph publish my-graph@production \ --schema ./schema.graphql \ --name orders \ --routing-url http://order-service:4002/graphqlАвторизация на уровне subgraph
Каждый subgraph самостоятельно проверяет права. Пример на TypeScript: в ресолвере Order
__resolveReferenceпроверяется, что текущий пользователь — владелец заказа или имеет роль admin. В случае отказа возвращается ошибкаForbiddenError.Почему Federation стоит выбрать для нового проекта?
Federation даёт независимость командам, атомарные деплои и автоматическую проверку совместимости. Мы гарантируем, что схема останется консистентной при каждом изменении. Это лучшее решение для компаний с 3+ микросервисами, где важна скорость изменений.
Что входит в работу?
- Аудит текущей архитектуры и выделение границ subgraph.
- Проектирование supergraph-схемы с @key и @requires.
- Реализация subgraph-сервисов (Node.js, Go, Python — любой стек).
- Настройка Apollo Router с CORS, авторизацией, мониторингом.
- Интеграция Managed Federation с CI-пайплайном проверки совместимости.
- Документация по схеме и точкам расширения.
- Обучение команды работе с Federation.
- Поддержка на старте: 2 недели после запуска.
Процесс работы и сроки
- Анализ — выделяем границы subgraph, определяем точки интеграции с legacy.
- Проектирование — описываем supergraph-схему, согласуем @key и @requires.
- Разработка — каждый subgraph создаётся как отдельный сервис с собственным деплоем.
- Настройка Router — конфигурация CORS, авторизации, мониторинга (Apollo Studio).
- Managed Federation — подключаем CI-пайплайн с проверкой совместимости.
- Тестирование — нагрузочное тестирование и E2E-тесты.
- Запуск — пошаговый rollout с мониторингом ошибок.
Сроки реализации:
- 2–3 subgraph с базовой Federation — 2–3 недели.
- Apollo Router + Managed Federation + CI-проверки совместимости — ещё 1 неделя.
- Сложные @requires, @provides, nested resolvers — 1–2 дополнительные недели.
Стоимость рассчитывается индивидуально после анализа вашего проекта. Получите консультацию — мы оценим объём работы и предложим оптимальное решение. Закажите внедрение Federation: свяжитесь с нами — подготовим предложение под ключ. Ваша архитектура станет гибкой и масштабируемой без лишних затрат.
Пример детальной реализации subgraph на TypeScript
Весь код User и Order subgraph доступен в репозитории. При необходимости адаптируем под ваш стек.Получите консультацию по внедрению Federation — напишите нам, и мы оценим ваш проект.