Federation and query complexity

Production GraphQL нуждается в ограничителях: **query cost**, **depth limits**, **timeouts** и явном **владении сервисами** в federated graphs.

**Federation** (Apollo, GraphQL Mesh) собирает subgraphs в supergraph. Каждая команда владеет types; gateway планирует fetch между сервисами.

					# users subgraph
type User @key(fields: "id") {
  id: ID!
  email: String!
}

# orders subgraph
extend type User @key(fields: "id") {
  id: ID! @external
  orders: [Order!]!
}
				

Контроль сложности:

• **Max depth** — лимит вложенных selections.
• **Cost analysis** — веса полей; отклонение дорогих запросов.
• **Persisted queries** — allowlist известных operation hashes в production.
• **Rate limits** на API key / user / IP.

Entity resolution пересекает границы сервисов — мониторьте latency gateway и partial failures (nullable fields vs errors).

На интервью: когда federation помогает масштабу организации, отладка cross-subgraph N+1, почему public GraphQL без лимитов опасен.

Типовые ошибки: god subgraph, циклические зависимости, admin fields на том же графе, что mobile, нет persisted operations в prod.

Компромисс: автономия federated против operational complexity — schema registry, composition checks, observability gateway.

Чеклист:

• Depth и complexity limits в production.
• Persisted или approved operations для public clients.
• Документированное @key ownership по командам.
• Метрики gateway: plan time, subgraph errors, p99 latency.