Hvordan fungerer GraphQL-federation for mikrotjenester?

Question

IT Interview Practice · Accepted Answer

**Federation** lar mange uavhengig deployede tjenester hver eie en del av én graf, som en **gateway** komponerer til ett enkelt schema klienter spør mot. Det er den moderne erstatningen for **schema stitching**, der en gateway manuelt slo sammen fjern-schemaer — federation flytter sammenslåingsreglene inn i selve subgrafene.

## 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 tjeneste er en **subgraf**. En type eies av én tjeneste og **utvides** av andre. `@key`-direktivet navngir feltet/feltene som identifiserer en entitet på tvers av tjenester.

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

# Reviews-subgrafen UTVIDER User med felt den eier
type User @key(fields: "id") {
  id: ID! @external          # deklarert et annet sted; referert her via nøkkel
  reviews: [Review!]!        # denne subgrafen bidrar med dette feltet
}
```

Når en spørring strekker seg over flere tjenester, **planlegger** gateway-en den: hent `User` fra Users, kall deretter Reviews-subgrafens **entity resolver** (`__resolveReference`) med `{ id }` for å fylle inn `reviews`.

```js
// Reviews-subgrafen resolver User-referansen gateway-en gir den
const resolvers = {
  User: {
    __resolveReference: (ref, ctx) => ctx.reviewLoader.load(ref.id),
  },
};
```

## Federation kontra stitching

Stitching sentraliserer sammenslåingslogikken i gateway-en (skjør, gateway-en må kjenne alle). Federation **desentraliserer** eierskap: team videreutvikler subgrafen sin uavhengig, og komposisjonen verifiseres i CI. Avveiningen er en mer kompleks gateway/router og spørringsplanlegging på tvers av tjenester.

## Hvorfor det er viktig

I stor skala kan ikke ett team eie et monolittisk schema. Intervjuere vil se at du forstår **entitetseierskap via `@key`, reference resolvers og spørringsplanlegging** — og hvorfor federation slår stitching for organisatorisk skalering, ikke bare teknisk eleganse.

Arkitekturen

Federation kontra stitching

Hvorfor det er viktig

Relaterte spørsmål