Hvordan fungerer GraphQL-federation for microservices?

Question

IT Interview Practice · Accepted Answer

**Federation** lader mange uafhængigt deployede services hver eje en del af én graf, som en **gateway** komponerer til et enkelt skema, klienter forespørger. Det er den moderne erstatning for **schema stitching**, hvor en gateway manuelt flettede fjern-skemaer sammen — federation flytter fletningsreglerne ind i subgraferne selv.

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

Hver service er en **subgraf**. En type ejes af én service og **extendes** af andre. `@key`-direktivet navngiver det/de felt(er), der identificerer en entitet på tværs af services.

```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 forespørgsel spænder over services, **planlægger** gatewayen den: hent `User` fra Users, kald derefter Reviews-subgrafens **entity resolver** (`__resolveReference`) med `{ id }` for at udfylde `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

Stitching centraliserer fletningslogik i gatewayen (skrøbelig, gatewayen skal kende alle). Federation **decentraliserer** ejerskab: teams udvikler deres subgraf uafhængigt, og komposition verificeres i CI. Afvejningen er en mere kompleks gateway/router og query planning på tværs af services.

## Hvorfor det betyder noget

Ved skala kan ét team ikke eje et monolitisk skema. Interviewere vil se, at du forstår **entitets-ejerskab via `@key`, reference-resolvers og query planning** — og hvorfor federation slår stitching for organisatorisk skalering, ikke blot teknisk elegance.

Arkitekturen

Federation vs. stitching

Hvorfor det betyder noget

Relaterede spørgsmål