Hogyan működik a GraphQL federation mikroszolgáltatásokhoz?

Question

IT Interview Practice · Accepted Answer

A **federation** lehetővé teszi, hogy sok, egymástól függetlenül deployolt szolgáltatás egy-egy részt birtokoljon egyetlen gráfból, amelyet egy **gateway** egyetlen sémává komponál, amit a kliensek lekérdeznek. Ez a **schema stitching** modern utódja, ahol egy gateway manuálisan egyesítette a távoli sémákat — a federation az egyesítési szabályokat magukba a subgraphokba helyezi át.

## Az architektúra

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

Minden szolgáltatás egy **subgraph**. Egy típust egy szolgáltatás birtokol, és mások **kiterjesztik**. A `@key` direktíva megnevezi azt a mezőt (mezőket), amely azonosít egy entitást a szolgáltatások között.

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

Amikor egy lekérdezés több szolgáltatást érint, a gateway **megtervezi**: lekéri a `User`-t a Users szolgáltatásból, majd meghívja a Reviews subgraph **entity resolverét** (`__resolveReference`) az `{ id }`-vel, hogy kitöltse a `reviews`-t.

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

A stitching a gatewayben központosítja az egyesítési logikát (törékeny, a gatewaynek mindenkit ismernie kell). A federation **decentralizálja** a tulajdonlást: a csapatok függetlenül fejlesztik a saját subgraphjukat, a kompozíciót pedig CI-ban verifikálják. A kompromisszum egy bonyolultabb gateway/router és a szolgáltatások közötti lekérdezés-tervezés.

## Miért fontos

Nagy léptékben egyetlen csapat sem birtokolhat egy monolitikus sémát. Az interjúztatók azt szeretnék látni, hogy érted az **entitás-tulajdonlást a `@key`-en keresztül, a reference resolvereket és a lekérdezés-tervezést** — és azt, hogy a federation miért jobb a stitchingnél a szervezeti skálázás szempontjából, nem csak technikai eleganciából.

Az architektúra

Federation vs stitching

Miért fontos

Kapcsolódó kérdések