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-схем.