Como funciona a federation do GraphQL para microsserviços?

Question

IT Interview Practice · Accepted Answer

**Federation** permite que muitos serviços implantados de forma independente possuam, cada um, parte de um grafo, que um **gateway** compõe em um único schema que os clientes consultam. É a substituição moderna do **schema stitching**, no qual um gateway mesclava manualmente schemas remotos — a federation move as regras de mesclagem para os próprios subgraphs.

## A arquitetura

```text
                 ┌────────────────────────┐
   Client ─────▶ │  Gateway / Router      │  (composed supergraph)
                 └───────┬────────┬───────┘
                         │        │  plans + fans out sub-queries
              ┌──────────▼──┐  ┌──▼──────────┐  ┌──────────────┐
              │ Users svc    │  │ Reviews svc │  │ Products svc │
              │  type User   │  │  extends    │  │  type Product│
              │  @key(id)    │  │  User/Prod  │  │  @key(id)    │
              └──────────────┘  └─────────────┘  └──────────────┘
```

Cada serviço é um **subgraph**. Um tipo pertence a um serviço e é **estendido** por outros. A diretiva `@key` nomeia o(s) campo(s) que identificam uma entidade entre os serviços.

```graphql
# Users subgraph OWNS User
type User @key(fields: "id") {
  id: ID!
  name: String!
}

# Reviews subgraph EXTENDS User with fields it owns
type User @key(fields: "id") {
  id: ID! @external          # declared elsewhere; referenced here by key
  reviews: [Review!]!        # this subgraph contributes this field
}
```

Quando uma consulta abrange serviços, o gateway a **planeja**: busca o `User` no serviço Users e depois chama o **entity resolver** do subgraph Reviews (`__resolveReference`) com `{ id }` para preencher `reviews`.

```js
// Reviews subgraph resolves the User reference the gateway hands it
const resolvers = {
  User: {
    __resolveReference: (ref, ctx) => ctx.reviewLoader.load(ref.id),
  },
};
```

## Federation vs. stitching

O stitching centraliza a lógica de mesclagem no gateway (frágil, o gateway precisa conhecer todo mundo). A federation **descentraliza** a propriedade: as equipes evoluem seu subgraph de forma independente, e a composição é verificada em CI. O trade-off é um gateway/router mais complexo e o planejamento de consultas entre serviços.

## Por que isso importa

Em escala, uma única equipe não consegue ser dona de um schema monolítico. Os entrevistadores querem ver que você entende **propriedade de entidade via `@key`, reference resolvers e planejamento de consultas** — e por que a federation supera o stitching para escalonamento organizacional, não apenas por elegância técnica.

A arquitetura

Federation vs. stitching

Por que isso importa

Perguntas relacionadas