GraphQL Federation: Membangun API Terdistribusi yang Skalabel dan Mudah Dikembangkan

1. Pendahuluan

Jika Anda sudah familiar dengan GraphQL, Anda pasti tahu betapa powerful-nya ia dalam memberikan klien kemampuan untuk meminta data persis yang mereka butuhkan. Ini adalah anugerah, terutama bagi developer frontend yang seringkali frustrasi dengan masalah over-fetching atau under-fetching data dari REST API tradisional.

Namun, seiring pertumbuhan aplikasi dan tim, terutama dalam arsitektur microservices, membangun dan mengelola GraphQL API bisa menjadi tantangan tersendiri. Bayangkan jika Anda memiliki puluhan microservices, dan semuanya ingin berkontribusi pada satu skema GraphQL yang besar.

📌 Masalahnya:

Monolit Skema: Skema GraphQL Anda bisa menjadi raksasa yang sulit dikelola (god schema), di mana satu perubahan kecil bisa berisiko memengaruhi bagian lain.
Koordinasi Tim: Tim yang berbeda harus berkoordinasi secara ketat setiap kali ada perubahan pada skema, memperlambat proses pengembangan.
Deployment Kompleks: Melakukan deployment atau scaling untuk bagian-bagian skema yang berbeda menjadi rumit karena semuanya terikat pada satu kesatuan.
Tanggung Jawab Tunggal: Satu tim mungkin harus bertanggung jawab atas seluruh skema, padahal data berasal dari berbagai layanan yang dikelola tim lain.

Di sinilah GraphQL Federation hadir sebagai penyelamat. Ini adalah pendekatan arsitektur yang memungkinkan Anda memecah skema GraphQL monolitik menjadi bagian-bagian yang lebih kecil, modular, dan dapat dikelola secara independen, yang disebut subgraph. Pendekatan ini sangat ideal untuk lingkungan microservices dan tim yang tersebar.

Dalam artikel ini, kita akan menyelami GraphQL Federation: apa itu, bagaimana cara kerjanya, manfaatnya, dan kapan Anda harus mempertimbangkannya untuk proyek Anda.

2. Mengapa GraphQL Federation? Tantangan di Balik Skema Monolitik

Mari kita ambil contoh sebuah platform e-commerce. Anda memiliki beberapa layanan inti:

Layanan Pengguna: Mengelola informasi pengguna (nama, email, alamat).
Layanan Produk: Mengelola detail produk (nama, harga, deskripsi).
Layanan Pesanan: Mengelola riwayat pesanan (produk apa saja, oleh siapa, kapan).

Tanpa Federation, semua layanan ini akan berkontribusi pada satu skema GraphQL besar. Misalnya, skema Anda mungkin terlihat seperti ini:

type User {
  id: ID!
  username: String!
  email: String!
  orders: [Order!]!
}

type Product {
  id: ID!
  name: String!
  price: Float!
  description: String
}

type Order {
  id: ID!
  user: User!
  products: [Product!]!
  orderDate: String!
  status: String!
}

type Query {
  users: [User!]!
  products: [Product!]!
  orders: [Order!]!
  # ... query lainnya
}

Dalam skema monolitik ini:

Jika tim Layanan Produk ingin menambahkan field baru ke Product, mereka harus berkoordinasi dengan tim lain yang mungkin terpengaruh.
Tim Layanan Pesanan tidak bisa begitu saja mengubah cara Order berinteraksi dengan User atau Product tanpa memengaruhi keseluruhan skema.
Setiap perubahan, bahkan yang kecil, memerlukan deployment ulang seluruh GraphQL API, yang bisa jadi lambat dan berisiko.

💡 GraphQL Federation memecahkan masalah ini dengan memungkinkan setiap layanan (atau tim) untuk memiliki dan mengelola bagian dari skema GraphQL secara independen. Bagian-bagian ini kemudian digabungkan menjadi satu skema yang utuh di tingkat gateway. Ini seperti membangun sebuah rumah dari banyak modul yang dibuat terpisah, lalu disatukan di lokasi akhir.

3. Konsep Dasar GraphQL Federation: Subgraph dan Gateway

GraphQL Federation memiliki dua komponen utama yang perlu Anda pahami:

a. Subgraph (Layanan GraphQL Independen)

Bayangkan subgraph sebagai microservice GraphQL Anda. Setiap subgraph adalah layanan mandiri yang:

Memiliki skema GraphQL-nya sendiri yang mendefinisikan tipe, field, dan resolver yang menjadi tanggung jawabnya.
Hanya tahu tentang data dan logika bisnis yang dikelolanya.
Berkomunikasi dengan database atau layanan backend-nya sendiri.
Dapat di-deploy dan di-scale secara independen.

Untuk memungkinkan gateway menyatukan skema-skema ini, subgraph menggunakan beberapa direktif khusus yang disediakan oleh spesifikasi Federation (umumnya Apollo Federation):

@key: Mendefinisikan field unik yang mengidentifikasi sebuah tipe di seluruh subgraph. Ini adalah kunci untuk menghubungkan data antar subgraph.
@external: Digunakan pada field yang dimiliki oleh subgraph lain tetapi diperlukan oleh subgraph ini untuk menyelesaikan query.
@requires: Menunjukkan bahwa field ini memerlukan field lain dari subgraph yang sama untuk diselesaikan.
@provides: Digunakan untuk menunjukkan bahwa subgraph ini dapat menyediakan field tertentu dari tipe yang di-extend oleh subgraph lain.

Contoh Skema Subgraph Produk:

# Produk Subgraph
type Product @key(fields: "id") {
  id: ID!
  name: String!
  price: Float!
  description: String
  # Field ini dimiliki oleh subgraph User, tapi Product perlu tahu siapa pembuatnya
  createdBy: User @external
}

# Kita perlu mendefinisikan tipe User di sini hanya untuk referensi
# agar kita bisa menggunakan createdBy: User.
# Perhatikan bahwa ini adalah "ekstensi" dari tipe User yang asli ada di Subgraph User.
extend type User @key(fields: "id") {
  id: ID! @external
}

b. Apollo Gateway (atau Router)

Gateway adalah titik masuk tunggal bagi semua permintaan klien. Ini adalah “otak” dari sistem Federation. Tugas utamanya adalah:

Menggabungkan Skema: Mengambil semua skema dari subgraph-subgraph dan menyatukannya menjadi satu skema GraphQL global yang utuh (disebut federated schema).
Menerima Kueri Klien: Menerima kueri GraphQL dari klien (frontend, aplikasi mobile, dll.).
Memecah Kueri: Menganalisis kueri klien dan memecahnya menjadi sub-kueri yang lebih kecil, masing-masing ditujukan untuk subgraph yang relevan.
Meneruskan Kueri: Mengirim sub-kueri ini ke subgraph yang sesuai.
Menggabungkan Hasil: Mengambil hasil dari berbagai subgraph dan menyatukannya kembali menjadi satu respons GraphQL tunggal yang koheren untuk klien.

💡 Analogi: Jika subgraph adalah musisi yang ahli memainkan instrumen mereka sendiri, maka Gateway adalah dirigen orkestra. Dirigen tidak memainkan instrumen, tetapi ia tahu bagian mana yang harus dimainkan setiap musisi dan kapan, lalu menyatukan semuanya menjadi simfoni yang harmonis.

4. Bagaimana GraphQL Federation Bekerja? Menjelajahi Proses Kueri

Mari kita lihat alur kerja ketika klien mengirim kueri ke sistem GraphQL Federation:

Klien Mengirim Kueri: Aplikasi frontend Anda mengirimkan kueri GraphQL ke Apollo Gateway. Klien tidak perlu tahu tentang subgraph-subgraph di belakangnya.

query GetProductDetails {
  product(id: "prod-123") {
    id
    name
    price
    createdBy {
      id
      username
      email
    }
  }
}

Gateway Menganalisis Kueri: Gateway menerima kueri ini. Berdasarkan skema gabungan yang telah dikompilasi dari semua subgraph, Gateway menganalisis kueri untuk menentukan data apa yang diminta dan subgraph mana yang bertanggung jawab atas data tersebut.
Gateway Membuat Rencana Eksekusi: Gateway membuat “rencana eksekusi” yang menentukan urutan panggilan ke subgraph-subgraph.
- product(id: "prod-123") dan field id, name, price adalah tanggung jawab Subgraph Produk.
- Field createdBy pada Product adalah tipe User yang di-extend dari Subgraph Pengguna. Untuk mendapatkan detail createdBy, Gateway perlu memanggil Subgraph Pengguna.
Gateway Mengirim Kueri ke Subgraph Produk: Gateway pertama-tama mengirimkan kueri ke Subgraph Produk untuk mendapatkan detail produk:
```
# Kueri internal ke Subgraph Produk
query ($_id: ID!) {
  product(id: $_id) {
    id
    name
    price
    createdBy {
      id # Hanya ID yang diperlukan untuk diteruskan ke subgraph User
    }
  }
}
```
Subgraph Produk mengembalikan data: {"id": "prod-123", "name": "Sepatu Keren", "price": 120.0, "createdBy": {"id": "user-456"}}.
Gateway Mengirim Kueri ke Subgraph Pengguna: Dengan id pengguna (user-456) yang diterima dari Subgraph Produk, Gateway kemudian mengirimkan kueri ke Subgraph Pengguna untuk mendapatkan detail createdBy:
```
# Kueri internal ke Subgraph Pengguna
query ($_id: ID!) {
  user(id: $_id) {
    id
    username
    email
  }
}
```
Subgraph Pengguna mengembalikan data: {"id": "user-456", "username": "john.doe", "email": "john@example.com"}.

Gateway Menggabungkan Hasil: Gateway mengambil hasil dari kedua subgraph dan menggabungkannya menjadi satu objek respons GraphQL yang lengkap dan koheren, sesuai dengan kueri asli klien.

{
  "data": {
    "product": {
      "id": "prod-123",
      "name": "Sepatu Keren",
      "price": 120.0,
      "createdBy": {
        "id": "user-456",
        "username": "john.doe",
        "email": "john@example.com"
      }
    }
  }
}

Gateway Mengirim Respons ke Klien: Respons akhir ini kemudian dikirim kembali ke klien.

Proses ini menunjukkan bagaimana Gateway berfungsi sebagai orkestrator yang cerdas, mampu menyatukan data dari berbagai sumber tanpa klien perlu tahu kompleksitas di baliknya.

5. Manfaat GraphQL Federation: Lebih dari Sekadar Skalabilitas

Mengadopsi GraphQL Federation membawa sejumlah keuntungan signifikan, terutama untuk proyek skala besar:

✅ Skalabilitas Tim yang Lebih Baik: _ Setiap tim dapat memiliki dan mengelola subgraph-nya sendiri. Ini mengurangi ketergantungan antar tim dan memungkinkan mereka untuk bekerja dan mendeploy secara independen. _ Tim dapat memilih teknologi backend yang berbeda untuk subgraph mereka, sesuai dengan kebutuhan spesifik layanan tersebut.

✅ Skalabilitas Aplikasi yang Mudah: * Anda dapat men-scale subgraph tertentu secara terpisah berdasarkan beban kerja, tanpa memengaruhi subgraph lain. Misalnya, jika layanan produk mengalami lonjakan traffic, Anda hanya perlu men-scale subgraph produk.

✅ Modularitas dan Reusabilitas: _ Skema menjadi lebih kecil, lebih fokus, dan lebih mudah dipahami. Ini meningkatkan kualitas kode dan mengurangi risiko kesalahan. _ Komponen skema yang didefinisikan dalam satu subgraph dapat dengan mudah digunakan atau diperluas oleh subgraph lain.

✅ Evolusi Skema yang Fleksibel: * Perubahan pada satu subgraph tidak serta-merta memerlukan perubahan atau deployment ulang pada subgraph lain atau gateway, selama kontrak @key dan @external tetap terjaga. Ini mempercepat siklus pengembangan.

✅ Konsistensi Data Global: * Meskipun skema terpecah, Gateway memastikan bahwa tampilan skema yang disajikan kepada klien adalah satu kesatuan yang konsisten.

Namun, tidak ada solusi yang tanpa tantangan:

❌ Kompleksitas Awal: * Memulai dengan GraphQL Federation bisa jadi lebih kompleks dibandingkan dengan GraphQL monolitik. Ada kurva pembelajaran untuk konsep subgraph, direktif, dan konfigurasi gateway.

❌ Overhead Jaringan: * Untuk kueri yang melibatkan banyak subgraph, Gateway mungkin perlu melakukan beberapa panggilan internal ke berbagai layanan, yang bisa menambah latensi dibandingkan dengan satu panggilan ke monolit.

❌ Debugging yang Lebih Rumit:

Melacak masalah di sistem terdistribusi yang melibatkan banyak layanan bisa lebih menantang. Alat observabilitas seperti *distributed tracing* menjadi sangat penting di sini.

6. Kapan Harus Menggunakan GraphQL Federation?

GraphQL Federation bukanlah solusi one-size-fits-all. Penting untuk memahami kapan ia paling bersinar:

🎯 Arsitektur Microservices: Jika Anda sudah memiliki arsitektur microservices atau berencana untuk migrasi ke sana, Federation adalah pasangan yang sempurna untuk GraphQL. Ini memungkinkan setiap microservice untuk “mengungkapkan” datanya melalui GraphQL tanpa harus membangun API gateway yang rumit secara manual.

🎯 Tim Besar dan Terdistribusi: Ketika Anda memiliki banyak tim yang bekerja secara independen pada bagian yang berbeda dari aplikasi, Federation memungkinkan mereka untuk memiliki kepemilikan penuh atas domain data mereka dalam skema GraphQL.

🎯 Skema GraphQL yang Sangat Besar: Jika skema GraphQL Anda terus tumbuh dan menjadi sulit dikelola oleh satu tim atau satu codebase, Federation membantu memecahnya menjadi bagian-bagian yang lebih kecil dan lebih terkelola.

🎯 Kebutuhan Evolusi Independen: Ketika Anda ingin tim dapat mengembangkan, menguji, dan mendeploy perubahan API mereka secara mandiri tanpa harus menunggu atau mengoordinasikan dengan tim lain.

❌ Kapan TIDAK menggunakannya: _ Untuk aplikasi monolitik kecil atau tim yang sangat kecil, kompleksitas awal dari Federation mungkin tidak sebanding dengan manfaatnya. Memulai dengan GraphQL monolitik mungkin lebih sederhana dan cukup. _ Jika latensi adalah masalah yang sangat kritis dan kueri Anda seringkali melibatkan banyak layanan, Anda perlu hati-hati mempertimbangkan overhead jaringan dan mungkin mengoptimalkan interaksi antar subgraph.

Kesimpulan

GraphQL Federation adalah arsitektur yang kuat dan canggih untuk membangun API GraphQL yang skalabel dan modular, terutama di lingkungan microservices. Ini memungkinkan tim Anda bekerja lebih efisien, mengurangi bottleneck, dan mempercepat pengembangan fitur. Dengan memecah skema monolitik menjadi subgraph-subgraph yang independen dan mengandalkan Gateway untuk menyatukannya, Anda bisa membangun sistem yang lebih tangguh dan mudah dikembangkan.

Jika Anda menghadapi tantangan dalam mengelola skema GraphQL yang terus berkembang, kesulitan koordinasi antar tim, atau ingin mengoptimalkan pengembangan di arsitektur microservices, GraphQL Federation patut Anda pertimbangkan sebagai fondasi API modern Anda. Ini adalah langkah maju untuk membawa GraphQL ke tingkat skalabilitas dan fleksibilitas enterprise.