Bagaimana GraphQL federation bekerja untuk microservices?

Question

IT Interview Practice · Accepted Answer

**Federation** memungkinkan banyak service yang dideploy secara independen masing-masing memiliki bagian dari satu graph, yang lalu disusun oleh sebuah **gateway** menjadi satu schema yang di-query client. Ini adalah pengganti modern untuk **schema stitching**, di mana sebuah gateway menggabungkan schema remote secara manual — federation memindahkan aturan penggabungan ke dalam subgraph itu sendiri.

## Arsitekturnya

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

Setiap service adalah sebuah **subgraph**. Sebuah tipe dimiliki oleh satu service dan **diperluas (extended)** oleh yang lain. Direktif `@key` menamai field yang mengidentifikasi sebuah entity lintas service.

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

Ketika sebuah query merentang beberapa service, gateway **merencanakan (plans)**-nya: ambil `User` dari Users, lalu panggil **entity resolver** (`__resolveReference`) milik subgraph Reviews dengan `{ id }` untuk mengisi `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 memusatkan logika penggabungan di gateway (rapuh, gateway harus tahu semua pihak). Federation **mendesentralisasi** kepemilikan: tim mengembangkan subgraph mereka secara independen, dan komposisinya diverifikasi di CI. Trade-off-nya adalah gateway/router yang lebih kompleks dan perencanaan query lintas-service.

## Mengapa ini penting

Pada skala besar, satu tim tidak bisa memiliki schema monolitik. Interviewer ingin melihat Anda memahami **kepemilikan entity lewat `@key`, reference resolver, dan query planning** — serta mengapa federation mengungguli stitching untuk penskalaan organisasi, bukan sekadar keanggunan teknis.

Arsitekturnya

Federation vs stitching

Mengapa ini penting

Pertanyaan terkait