Belajar GraphQL - Microservices Architecture Patterns

#Pendahuluan

Microservices memberi kebebasan deploy dan skala per-domain — tetapi membawa kompleksitas baru: data terpecah, komunikasi antar-service, dan konsistensi. Episode 36 menghubungkan GraphQL dengan dunia microservices secara menyeluruh.

Kita akan membahas pola gateway, federation deep dive, arsitektur event-driven, integrasi message broker, dan service discovery.

#Microservices Patterns

#GraphQL Gateway untuk Microservices

Di episode 22 kalian membangun federation. Pola ini adalah fondasi GraphQL untuk microservices: setiap service memiliki subgraph-nya sendiri, dan gateway menyatukannya menjadi satu schema untuk client.

Kunci suksesnya ada di batas domain yang bersih:

• Setiap service memiliki data dan schema yang jelas.
• Kontrak antar-service eksplisit lewat direktif federation.
• Tidak ada service yang mengakses database service lain secara langsung.

gateway
  -> user-service (subgraph users)
  -> order-service (subgraph orders)
  -> payment-service (subgraph payments)

#Inter-Service Communication

Komunikasi antar-service memakai dua pola utama: synchronous (panggilan HTTP/gRPC langsung) dan asynchronous (event melalui message broker). GraphQL pada umumnya memakai yang pertama untuk query, dan yang kedua untuk konsistensi data.

#Apollo Federation Deep Dive

#Entity Resolution dan Optimasi

Federation menghadapi tantangan unik: satu entitas tersebar di banyak service. __resolveReference (episode 22) menjadi mekanisme perakitan entitas. Optimasinya:

• Pastikan __resolveReference memakai DataLoader agar reference batch di-batch.
• Batasi jumlah field @external — semakin banyak yang dibutuhkan service lain, semakin mahal query planning.
• Gunakan @requires dengan bijak agar gateway tidak perlu memanggil banyak service.

#Cross-Service Transactions dan Monitoring

Transaction lintas service tidak bisa dijamin ACID biasa. Pola yang dipakai: saga — urutan langkah dengan kompensasi bila salah satu gagal. Untuk monitoring, setiap subgraph mengirim trace ke Apollo Studio (episode 24) sehingga perjalanan satu query melintasi beberapa service terlihat jelas.

#Event-Driven Architecture

#Event Sourcing dan CQRS

Untuk domain yang butuh riwayat lengkap, terapkan event sourcing: setiap perubahan disimpan sebagai event yang immutable, dan state saat ini diturunkan dari event stream. CQRS memisahkan model baca (query GraphQL) dari model tulis (mutation dan command).

type OrderEvent {
  id: ID!
  type: String!
  occurredAt: DateTime!
  data: JSON!
}
 
type Query {
  orderEvents(orderId: ID!): [OrderEvent!]!
}

Manfaatnya: audit trail lengkap dan query historis. Kompleksitasnya tinggi — hanya gunakan bila memang butuh.

#Message Brokers: Kafka dan RabbitMQ

Message broker memungkinkan komunikasi asynchronous antar-service; install klien Kafka dengan npm install kafkajs:

Publish dan subscribe event

import { Kafka } from "kafkajs";
 
const kafka = new Kafka({ brokers: ["localhost:9092"] });
const producer = kafka.producer();
const consumer = kafka.consumer({ groupId: "graphql-service" });
 
await producer.connect();
await producer.send({
  topic: "order.created",
  messages: [{ value: JSON.stringify(order) }],
});
 
await consumer.subscribe({ topic: "order.created" });
await consumer.run({
  eachMessage: async ({ message }) => {
    await handleOrderCreated(JSON.parse(message.value));
  },
});

Pola yang umum: mutation GraphQL menulis ke database utama dan mem-publish event ke broker; service lain mendengarkan event tersebut untuk menyinkronkan data mereka (misalnya service analytics). Inilah dasar eventual consistency.

#Eventual Consistency

Karena data tersebar di banyak service, konsistensi instan sulit dicapai. Prinsipnya: layanan utama merespons client segera, sedangkan data turunan (denormalisasi) disinkronkan lewat event. GraphQL di sisi client harus siap menangani data yang "tidak seketika" konsisten — inilah alasan pola refetch dan optimistic UI (episode 25) sangat berguna.

#Service Discovery

#Konsul dan Kubernetes

Di dunia microservices, service tidak lagi punya alamat statis. Service discovery memecahkan masalah "di mana service lain berada":

• Kubernetes DNS: service ditemukan lewat nama DNS internal (user-service.default.svc.cluster.local).
• Consul: service mendaftarkan diri, client menemukan lewat API discovery.

apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
  ports:
    - port: 4001
      targetPort: 4001

Gateway federation memakai service discovery untuk menemukan subgraph: alih-alih URL statis, subgraph diregistrasi dan ditemukan secara dinamis. Ini membuat penambahan atau penggantian service tidak mengganggu client.

#Penutup

Inti yang harus dibawa pulang:

• Gateway federation adalah pola utama GraphQL untuk microservices.
• __resolveReference dengan DataLoader dan @requires yang bijak menjaga performa.
• Saga dan event sourcing mengelola konsistensi lintas service.
• Message broker seperti Kafka menyinkronkan data antar-service secara async.
• Eventual consistency mengharuskan client menangani data yang tidak instan.
• Service discovery (Kubernetes, Consul) memungkinkan gateway menemukan subgraph dinamis.

Di episode 37 selanjutnya kalian akan mempelajari GraphQL dan serverless architecture — best practices serverless seperti optimasi cold start, AWS Lambda dengan API Gateway, edge computing dengan Cloudflare Workers dan Vercel Edge, hingga manajemen koneksi database dengan RDS Proxy dan PlanetScale. GraphQL kalian akan berjalan di mana pun tanpa server!