Federation и gateway: Hot Chocolate Fusion
↑ 5.3 GraphQL на бэкенде и Federation · ← Предыдущая · → Следующая
Зачем это на собесе
Как объединить схемы нескольких микросервисов в один граф для клиентов.
Объяснение
Каждый сервис владеет частью графа (заказы, клиенты, каталог), а gateway объединяет их в единую схему и раздаёт запрос нужным сервисам.
flowchart LR C[Клиент] --> G[Gateway / Fusion] G --> O[Orders subgraph] G --> U[Users subgraph] G --> P[Catalog subgraph]
| Решение | Особенности |
|---|---|
| Apollo Federation | стандарт де-факто: @key, @extends, router |
| Hot Chocolate Fusion | .NET-нативный gateway, композиция схем в fusion-конфигурацию |
| Schema stitching | старый подход, ручное связывание |
Ключевые идеи:
- Entity: тип, разделяемый между сервисами и идентифицируемый ключом (
User @key(fields: "id")). - Сервис заказов ссылается на пользователя по id, а сервис пользователей «дополняет» тип полями.
- Gateway строит план запроса: какие сервисы вызвать и в каком порядке, объединяя результаты.
- Схемы композируются на этапе сборки (CI), gateway получает готовую конфигурацию.
Нюансы и подводные камни
- Один запрос клиента порождает несколько внутренних: следите за latency и N+1 между сервисами (батчинг по ключам).
- Владение полями должно быть чётким; конфликты имён ломают композицию.
- Авторизация и трассировка должны проходить через gateway (пробрасывайте токен и trace id).
- Изменения схемы подграфа проверяйте на совместимость в CI до релиза.
- Не делайте gateway «умным»: бизнес-логика остаётся в сервисах.
Практика
- Поднимите два подграфа и gateway на Fusion, свяжите
Order.customer. - Проверьте план выполнения и число внутренних запросов.
- Добавьте проверку композиции схемы в CI.
Вопросы с ответами
Что такое federation?
Модель, где несколько независимых GraphQL-сервисов образуют единый граф под общим gateway.
Чем плох один монолитный GraphQL-сервер для многих команд?
Связывает релизы команд; federation позволяет им независимо владеть частями схемы.