GraphQL Federation: объединение микросервисов в единый граф

Представьте: у вас три микросервиса — 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:

1. Получает заказы из Orders Subgraph.
2. Извлекает все userId и productId.
3. Параллельно отправляет один _entities запрос в Users и Products Subgraph.
4. Сливает результаты и отдаёт клиенту.

Для этого в subgraph'ах реализуется __resolveReference — функция, которая по id возвращает сущность. Мы обязательно используем DataLoader внутри __resolveReference для батчинга внутри самого subgraph'а — это повышает производительность в 3 раза.

Почему Apollo Federation, а не Schema Stitching?

Если у вас 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.

Процесс работы

Какие типичные ошибки встречаются при внедрении?

Что входит в работу

• Документация 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.