GraphQL Federation: об'єднання мікросервісів у єдиний граф

Уявіть: у вас три мікросервіси — Users, Products, Orders. Кожен має свій GraphQL-ендпоінт. Клієнт робить три окремі запити і сам зліплює дані. Підсумок — високий TTFB (до 800 мс), дублювання логіки на фронтенді та помилки при зміні схеми. GraphQL Federation — це об'єднання мікросервісів у federated граф. Apollo Federation 2 вирішує це однією точкою входу. Router (написаний на Rust) приймає єдиний запит, будує план виконання і паралельно звертається до subgraph'ів — клієнт не знає про внутрішню структуру. Економія на інфраструктурі складає до $2000 на місяць. Вартість впровадження — від $5000, що окупається за 3 місяці за рахунок економії на інфраструктурі. Наша команда має 5+ років досвіду з GraphQL та 30+ успішних проєктів на Federation. Ми гарантуємо стабільність federated графу навіть при одночасному розгортанні кількох subgraph'ів. Замовте аудит вашої поточної архітектури — ми виявимо вузькі місця та підготуємо план міграції.

Об'єднайте мікросервіси в єдиний граф даних за допомогою Apollo Federation — це рішення ідеально підходить для мікросервісної архітектури. Без вирішення проблем координації та продуктивності ви ризикуєте отримати каскадні запити, падіння LCP та незадоволених користувачів. Federation — це не просто модний патерн, а спосіб інкапсулювати доменні межі та забезпечити швидку ітерацію.

Як GraphQL Federation вирішує проблему N+1 запитів?

GraphQL Federation вирішує проблему N+1 запитів через автоматичний entity batching. Без Federation кожен subgraph викликає інший синхронно — виникає каскад запитів. Apollo Router вирішує це через _entities query: замість 10 окремих викликів до сервісу продуктів — один батч, що скорочує час відповіді з 800 мс до 300 мс та знижує навантаження на БД в 3 рази. Це також зменшує кількість HTTP-запитів на 95%. Підвищує пропускну здатність (throughput) в 5 разів.

Складність інтеграції команд знімається: кожна команда володіє своїм 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 простіше. Але при масштабуванні Apollo Federation в 3 рази швидше, ніж Schema Stitching, завдяки Rust-ядру Router, що дає порядок в архітектурі. Apollo Federation краще за Schema Stitching в 3 рази за продуктивністю та зменшує кількість HTTP-запитів в 20 разів.

Як ми це робимо: кейс з нашої практики з трьома subgraph'ами

Ось приклад з нашої практики. Наприклад, для нашого клієнта з ритейлу впровадження Federation дозволило скоротити час відповіді з 1.2 с до 0.4 с, зменшити навантаження на базу даних на 60% та прискорити виведення нових функцій на 50%.

Типовий стек: 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.

Процес роботи

Типові помилки при впровадженні

• Неправильно вказані @key(fields:) — Router не зможе склеювати сутності.
• Відсутній DataLoader в __resolveReference — кожен entity-запит б'є в БД окремо.
• Не налаштовано propagate заголовків — втрачається контекст авторизації.
• Занадто глибока вкладеність (max_depth > 20) — Router будує важкі плани.
• Забули про @external для полів іншого subgraph'а — composition впаде.

Що входить в роботу

Ми пропонуємо впровадження Apollo Federation під ключ. До складу входить:

• Документація federated схеми та інструкції для команд.
• Доступи до Apollo Studio (або локального Registry) для публікації.
• Навчання команди роботі з Rover CLI та DataLoader.
• Підтримка протягом першого місяця після запуску (консультації, багфікс).

Оцініть проєкт — наші інженери проаналізують вашу схему за 2 години та запропонують оптимальне рішення. Зв'яжіться з нами для консультації з архітектури federated graph.

Строки та вартість

Налаштування Apollo Federation 2 з Router, composition pipeline та 3–5 subgraph'ами — 5–8 робочих днів. Вартість — від $5000 (економія до $2000/міс на інфраструктурі). Строк може збільшитися, якщо потрібна міграція з Schema Stitching або рефакторинг legacy-схем.