Miten GraphQL-federaatio toimii mikropalveluille?

Question

IT Interview Practice · Accepted Answer

**Federaatio** antaa monien itsenäisesti deployattujen palveluiden kunkin omistaa osan yhdestä graafista, jonka **gateway** komponoi yhdeksi schemaksi, jota clientit kyselevät. Se on moderni korvaaja **schema stitchingille**, jossa gateway yhdisti manuaalisesti etäschemat — federaatio siirtää yhdistämissäännöt itse subgraafeihin.

## Arkkitehtuuri

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

Jokainen palvelu on **subgraafi**. Tyypin omistaa yksi palvelu ja muut **laajentavat** (extend) sitä. `@key`-direktiivi nimeää kentän/kentät, jotka identifioivat entiteetin palveluiden välillä.

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

Kun kysely ulottuu useaan palveluun, gateway **suunnittelee** sen: hakee `User`in Users-palvelusta, kutsuu sitten Reviews-subgraafin **entity-resolveria** (`__resolveReference`) arvolla `{ id }` täyttääkseen `reviews`in.

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

## Federaatio vs. stitching

Stitching keskittää yhdistämislogiikan gatewayhin (hauras, gatewayn on tunnettava kaikki). Federaatio **hajauttaa** omistajuuden: tiimit kehittävät subgraafiaan itsenäisesti, ja komposition oikeellisuus varmistetaan CI:ssä. Kompromissina on monimutkaisempi gateway/router ja palveluiden välinen kyselyn suunnittelu.

## Miksi se on tärkeää

Skaalassa yksi tiimi ei voi omistaa monoliittista schemaa. Haastattelijat haluavat nähdä, että ymmärrät **entiteettien omistajuuden `@key`in kautta, reference-resolverit ja kyselyn suunnittelun** — ja miksi federaatio voittaa stitchingin organisatorisessa skaalautumisessa, ei vain teknisessä eleganssissa.

Arkkitehtuuri

Federaatio vs. stitching

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset