Come funziona la federation di GraphQL per i microservizi?

Question

IT Interview Practice · Accepted Answer

La **federation** permette a molti servizi distribuiti in modo indipendente di possedere ciascuno una parte di un unico grafo, che un **gateway** compone in un singolo schema interrogabile dai client. È la sostituzione moderna dello **schema stitching**, in cui un gateway univa manualmente schemi remoti — la federation sposta le regole di unione all'interno dei subgraph stessi.

## L'architettura

```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)    │
              └──────────────┘  └─────────────┘  └──────────────┘
```

Ogni servizio è un **subgraph**. Un tipo è di proprietà di un servizio ed **esteso** da altri. La direttiva `@key` indica il campo (o i campi) che identifica un'entità tra i servizi.

```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 una query attraversa più servizi, il gateway la **pianifica**: recupera lo `User` da Users, poi chiama l'**entity resolver** del subgraph Reviews (`__resolveReference`) con `{ id }` per riempire `reviews`.

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

## Federation contro stitching

Lo stitching centralizza la logica di unione nel gateway (fragile, il gateway deve conoscere tutti). La federation **decentralizza** la proprietà: i team fanno evolvere il proprio subgraph in modo indipendente e la composizione viene verificata in CI. Il compromesso è un gateway/router più complesso e la pianificazione di query tra servizi.

## Perché è importante

Su larga scala, un singolo team non può possedere uno schema monolitico. Gli intervistatori vogliono vedere che comprendi la **proprietà delle entità tramite `@key`, i reference resolver e la pianificazione delle query** — e perché la federation batte lo stitching per la scalabilità organizzativa, non solo per l'eleganza tecnica.

L'architettura

Federation contro stitching

Perché è importante

Domande correlate