Kako GraphQL federacija funkcionira za mikroservise?

Question

IT Interview Practice · Accepted Answer

**Federacija** omogućuje da mnogo neovisno deployanih servisa svaki posjeduje dio jednog grafa, koji **gateway** sastavlja u jednu shemu koju klijenti upituju. To je moderna zamjena za **schema stitching**, gdje je gateway ručno spajao udaljene sheme — federacija premješta pravila spajanja u same subgrafove.

## Arhitektura

```text
                 ┌────────────────────────┐
   Client ─────▶ │  Gateway / Router      │  (sastavljeni supergraf)
                 └───────┬────────┬───────┘
                         │        │  planira + raspršuje podupite
              ┌──────────▼──┐  ┌──▼──────────┐  ┌──────────────┐
              │ Users svc    │  │ Reviews svc │  │ Products svc │
              │  type User   │  │  extends    │  │  type Product│
              │  @key(id)    │  │  User/Prod  │  │  @key(id)    │
              └──────────────┘  └─────────────┘  └──────────────┘
```

Svaki servis je **subgraf**. Tip posjeduje jedan servis, a drugi ga **proširuju**. Direktiva `@key` imenuje polje (ili polja) koja identificiraju entitet među servisima.

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

# Reviews subgraf PROŠIRUJE User poljima koja posjeduje
type User @key(fields: "id") {
  id: ID! @external          # deklarirano drugdje; ovdje referencirano ključem
  reviews: [Review!]!        # ovaj subgraf doprinosi ovim poljem
}
```

Kada upit obuhvaća više servisa, gateway ga **planira**: dohvati `User` iz Users, zatim pozovi **entity resolver** (`__resolveReference`) Reviews subgrafa s `{ id }` kako bi popunio `reviews`.

```js
// Reviews subgraf razrješava User referencu koju mu gateway predaje
const resolvers = {
  User: {
    __resolveReference: (ref, ctx) => ctx.reviewLoader.load(ref.id),
  },
};
```

## Federacija naspram stitchinga

Stitching centralizira logiku spajanja u gatewayu (krhko, gateway mora poznavati sve). Federacija **decentralizira** vlasništvo: timovi neovisno razvijaju svoj subgraf, a kompozicija se provjerava u CI-ju. Kompromis je složeniji gateway/router i planiranje upita među servisima.

## Zašto je to važno

Pri velikoj skali jedan tim ne može posjedovati monolitnu shemu. Ispitivači žele vidjeti da razumijete **vlasništvo nad entitetima putem `@key`, reference resolvere i planiranje upita** — te zašto federacija nadmašuje stitching za organizacijsko skaliranje, a ne samo za tehničku eleganciju.

Arhitektura

Federacija naspram stitchinga

Zašto je to važno

Povezana pitanja