Wie funktioniert GraphQL-Federation für Microservices?

Question

IT Interview Practice · Accepted Answer

**Federation** lässt viele unabhängig deployte Dienste jeweils einen Teil eines Graphen besitzen, den ein **Gateway** zu einem einzigen Schema zusammenführt, das Clients abfragen. Es ist der moderne Ersatz für **Schema Stitching**, bei dem ein Gateway entfernte Schemas manuell zusammenführte – Federation verlagert die Merge-Regeln in die Subgraphen selbst.

## Die Architektur

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

Jeder Dienst ist ein **Subgraph**. Ein Typ gehört einem Dienst und wird von anderen **erweitert**. Die `@key`-Direktive benennt das oder die Feld(er), das bzw. die eine Entität dienstübergreifend identifiziert.

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

Wenn eine Abfrage mehrere Dienste umspannt, **plant** das Gateway sie: den `User` aus Users holen, dann den **Entity-Resolver** (`__resolveReference`) des Reviews-Subgraphen mit `{ id }` aufrufen, um `reviews` zu füllen.

```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 zentralisiert die Merge-Logik im Gateway (fragil, das Gateway muss alle kennen). Federation **dezentralisiert** die Ownership: Teams entwickeln ihren Subgraphen unabhängig weiter, und die Komposition wird in der CI verifiziert. Der Trade-off ist ein komplexeres Gateway/Router und dienstübergreifende Query-Planung.

## Warum es wichtig ist

Bei großem Maßstab kann ein Team kein monolithisches Schema besitzen. Interviewer wollen sehen, dass du **Entity-Ownership via `@key`, Reference-Resolver und Query-Planung** verstehst – und warum Federation Stitching für die organisatorische Skalierung schlägt, nicht nur aus technischer Eleganz.

Die Architektur

Federation vs. Stitching

Warum es wichtig ist

Ähnliche Fragen