Уявіть: у вас три мікросервіси — 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:
- Отримує замовлення з 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) — в 3 рази швидше | Середня (Node.js) |
Якщо у вас 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.
Процес роботи
| Етап | Час (дні) | Результат |
|---|---|---|
| Аналітика | 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 впаде.
Що входить в роботу
Ми пропонуємо впровадження 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-схем.