Kepiye carane GraphQL federation mlaku kanggo microservice?

Question

IT Interview Practice · Accepted Answer

**Federation** ngidini akeh layanan sing di-deploy kanthi mandhiri saben nduweni bagean saka siji graph, sing banjur digabungake **gateway** dadi siji schema sing di-query klien. Iki minangka panggantos modern kanggo **schema stitching**, ing ngendi gateway kanthi manual nggabung schema remot — federation mindhah aturan gabung menyang subgraph-e dhewe.

## Arsitekture

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

Saben layanan iku **subgraph**. Sawijining type diduweni siji layanan lan **diperluas** dening liyane. Directive `@key` menehi jeneng field(-field) sing nemtokake sawijining entitas ing antarane layanan.

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

Nalika sawijining query nyakup pirang-pirang layanan, gateway **ngrencanakake**: njupuk `User` saka Users, banjur nyeluk **entity resolver** subgraph Reviews (`__resolveReference`) nganggo `{ id }` kanggo ngisi `reviews`.

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

Stitching mumpuk logika gabung ing gateway (rapuh, gateway kudu ngerti kabeh wong). Federation **ndesentralisasi** kepemilikan: tim ngembangake subgraph-e kanthi mandhiri, lan komposisi diverifikasi ing CI. Trade-off-e yaiku gateway/router sing luwih rumit lan perencanaan query antar-layanan.

## Kenapa iki penting

Ing skala gedhe, siji tim ora bisa nduweni schema monolitik. Pewawancara pengin ndeleng yen kowe ngerti **kepemilikan entitas liwat `@key`, reference resolver, lan perencanaan query** — lan kenapa federation ngluwihi stitching kanggo penskalaan organisasi, dudu mung keanggunan teknis.

Arsitekture

Federation vs stitching

Kenapa iki penting

Pitakon sing gegandhengan