Kako deluje GraphQL federacija za mikrostoritve?

Question

IT Interview Practice · Accepted Answer

**Federacija** omogoča, da veliko neodvisno nameščenih storitev vsaka poseduje del enega grafa, ki ga **gateway** sestavi v eno samo shemo, po kateri odjemalci poizvedujejo. Je sodobna zamenjava za **schema stitching**, kjer je gateway ročno združeval oddaljene sheme — federacija premakne pravila združevanja v same podgrafe.

## Arhitektura

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

Vsaka storitev je **podgraf**. Tip poseduje ena storitev, druge pa ga **razširijo**. Direktiva `@key` poimenuje polje ali polja, ki identificirajo entiteto med storitvami.

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

Ko poizvedba sega čez več storitev, jo gateway **načrtuje**: pridobi `User` iz Users, nato pokliče **entitetni resolver** podgrafa Reviews (`__resolveReference`) z `{ id }`, da zapolni `reviews`.

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

## Federacija proti stitchingu

Stitching centralizira logiko združevanja v gateway (krhko, gateway mora poznati vse). Federacija **decentralizira** lastništvo: ekipe neodvisno razvijajo svoj podgraf, kompozicija pa se preverja v CI. Kompromis je bolj kompleksen gateway/router in načrtovanje poizvedb čez storitve.

## Zakaj je to pomembno

Pri velikem obsegu ena ekipa ne more posedovati monolitne sheme. Izpraševalci želijo videti, da razumeš **lastništvo entitet prek `@key`, referenčne resolverje in načrtovanje poizvedb** — ter zakaj je federacija boljša od stitchinga za organizacijsko skaliranje, ne le za tehnično eleganco.

Arhitektura

Federacija proti stitchingu

Zakaj je to pomembno

Povezana vprašanja