Jak działa federacja GraphQL dla mikroserwisów?

Question

IT Interview Practice · Accepted Answer

**Federacja** pozwala wielu niezależnie wdrażanym usługom posiadać po części jednego grafu, który **gateway** komponuje w pojedynczy schemat odpytywany przez klientów. To nowoczesny zamiennik **schema stitching**, gdzie gateway ręcznie scalał zdalne schematy — federacja przenosi reguły scalania do samych subgrafów.

## Architektura

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

Każda usługa to **subgraf**. Typ jest posiadany przez jedną usługę i **rozszerzany** przez inne. Dyrektywa `@key` nazywa pole (pola), które identyfikuje encję między usługami.

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

Gdy zapytanie obejmuje wiele usług, gateway je **planuje**: pobiera `User` z Users, a następnie wywołuje **entity resolver** subgrafu Reviews (`__resolveReference`) z `{ id }`, aby uzupełnić `reviews`.

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

## Federacja kontra stitching

Stitching centralizuje logikę scalania w gatewayu (kruche, gateway musi znać wszystkich). Federacja **decentralizuje** własność: zespoły rozwijają swój subgraf niezależnie, a kompozycja jest weryfikowana w CI. Kompromisem jest bardziej złożony gateway/router i planowanie zapytań między usługami.

## Dlaczego to ważne

Przy skali jeden zespół nie może posiadać monolitycznego schematu. Rekruterzy chcą zobaczyć, że rozumiesz **własność encji przez `@key`, reference resolvery i planowanie zapytań** — oraz dlaczego federacja bije stitching w skalowaniu organizacyjnym, a nie tylko w technicznej elegancji.

Architektura

Federacja kontra stitching

Dlaczego to ważne

Powiązane pytania