Hur fungerar GraphQL-federation för mikrotjänster?

Question

IT Interview Practice · Accepted Answer

**Federation** låter många oberoende driftsatta tjänster äga var sin del av en och samma graf, som en **gateway** komponerar till ett enda schema som klienter frågar mot. Det är den moderna ersättaren för **schema stitching**, där en gateway manuellt slog samman fjärrscheman — federation flyttar sammanslagningsreglerna in i subgraferna själva.

## Arkitekturen

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

Varje tjänst är en **subgraf**. En typ ägs av en tjänst och **utökas** av andra. Direktivet `@key` namnger fältet/fälten som identifierar en entitet över tjänsterna.

```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
}
```

När en fråga sträcker sig över flera tjänster **planerar** gatewayen den: hämta `User` från Users, och anropa sedan Reviews-subgrafens **entitets-resolver** (`__resolveReference`) med `{ id }` för att fylla i `reviews`.

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

## Federation mot stitching

Stitching centraliserar sammanslagningslogiken i gatewayen (skört, gatewayen måste känna till alla). Federation **decentraliserar** ägarskapet: team vidareutvecklar sin subgraf oberoende, och kompositionen verifieras i CI. Avvägningen är en mer komplex gateway/router och frågeplanering över flera tjänster.

## Varför det är viktigt

Vid stor skala kan inte ett enda team äga ett monolitiskt schema. Intervjuare vill se att du förstår **entitetsägarskap via `@key`, referens-resolvers och frågeplanering** — och varför federation slår stitching för organisatorisk skalning, inte bara teknisk elegans.

Arkitekturen

Federation mot stitching

Varför det är viktigt

Relaterade frågor