Sesi 23: Bahasa yang Dipakai Layanan untuk Bicara

1. Bayangkan jika —

Kamu punya microservice Order. Setiap kali order masuk, dia bertanya ke tiga layanan: User (ambil nama dan tier), Product (ambil harga dan stok), Voucher (periksa apakah voucher masih valid).

Masalahnya: User mengirim kembali seluruh profil pengguna — termasuk alamat, nomor HP, riwayat login, dan 40 field lain yang tidak kamu butuhkan. Kamu cuma mau satu field: loyalty_tier.

Di sisi lain, Voucher hanya diterima setelah tiga panggilan terpisah: pertama untuk cek kode, kedua untuk cek kedaluwarsa, ketiga untuk cek kuota tersisa — padahal ketiganya bisa dijawab sekaligus jika kamu bisa merinci pertanyaanmu.

Dua masalah yang berlawanan arah, tapi satu akar penyebab: format percakapan yang tidak cocok dengan kebutuhan nyata.

---

2. Apa yang Sebenarnya Terjadi

REST — Bahasa yang Semua Orang Paham

REST (Representational State Transfer) bekerja di atas HTTP biasa. Tiap resource punya URL, tiap operasi punya verb (GET, POST, PUT, DELETE). Mudah di-debug (buka browser, ketik URL, lihat hasilnya), mudah dipahami siapapun yang pernah memakai web.

Tapi REST berbicara dalam unit "resource" — kamu mendapat satu baris data penuh, bukan hanya field yang kamu minta. Ini disebut over-fetching: bandwidth dan waktu parsing terbuang untuk data yang langsung dibuang.

Masalah sebaliknya adalah under-fetching: satu endpoint tidak cukup, dan kamu harus memanggil beberapa endpoint berbeda untuk mengumpulkan semua yang dibutuhkan — yang dikenal sebagai N+1 problem.

gRPC — Kontrak Ketat, Kecepatan Tinggi

gRPC menggunakan Protocol Buffers (protobuf) sebagai skema kontrak: kamu mendefinisikan struktur data dan method terlebih dahulu dalam file .proto, lalu kode client dan server di-generate otomatis.

Karirnya: data disampaikan dalam format biner (bukan teks JSON), menghindari overhead serialisasi/deserialisasi teks. Komunikasi dilakukan lewat HTTP/2, yang mendukung multiplexing (satu koneksi TCP menangani banyak permintaan bersamaan) dan streaming dua arah.

Harganya: jauh lebih sulit di-debug oleh manusia (data biner tidak bisa dibaca di browser), butuh HTTP/2 di seluruh jalur, dan evolusi schema harus sangat hati-hati agar tidak memecah kompatibilitas mundur.

GraphQL — Klien yang Memilih Sendiri

GraphQL membalikkan paradigma: bukan server yang menentukan bentuk data, tapi klien yang mendefinisikan query. Klien Order bisa bertanya:

query {
  user(id: "U-991") { loyalty_tier }
  voucher(code: "HEMAT20") { valid expires_at remaining_quota }
}

Satu permintaan, jawaban tepat seperti yang diminta. Tidak lebih, tidak kurang.

Harganya: semua query masuk ke satu titik — resolver — yang memproses query. Resolver yang kurang dioptimasi bisa menjadi sangat mahal saat query dalam, bersarang, atau diizinkan query sembarang kombinasi. Inilah yang disebut resolver N+1 problem di GraphQL: satu field di level atas yang memicu ribuan query terpisah ke database di level bawah.

---

3. Bagaimana Jika Kita Coba...

"Buat saja satu endpoint per use case." Terasa wajar — tapi tidak berskala. Enam tim, dua puluh use case, dan kamu akhirnya punya dua puluh endpoint yang masing-masing adalah variasi dari data yang sama. Perubahan skema satu field menjadi opera koordinasi.

"Pakai gRPC saja untuk semua." Benar bahwa gRPC lebih efisien. Tapi layanan eksternal yang dikonsumsi browser dan aplikasi mobile tidak bisa langsung bicara gRPC — HTTP/2 di browser punya batasan, dan tooling debugging tim menjadi lebih panjang. Tidak ada protokol yang bisa jadi jawaban universal.

---

4. Nama Resminya

Dalam design doc, kamu akan melihat: - REST: GET /users/{id}, POST /orders - gRPC: blok service OrderService { rpc CreateOrder (OrderRequest) returns (OrderResponse); } - GraphQL: endpoint tunggal /graphql dengan schema type Query { ... }

---

5. Di Dunia Kita

Di sistem produksi skala besar, ketiga protokol ini hidup bersamaan bukan bersaing:

• REST di northbound API: endpoint yang dikonsumsi frontend dan mitra eksternal, karena ekosistem dan toolingnya paling luas.
• gRPC di east-west internal: komunikasi antar microservice di dalam cluster, di mana latensi rendah dan schema typing ketat adalah prioritas.
• GraphQL di layer agregasi: BFF (Backend For Frontend) yang mengumpulkan data dari banyak layanan dan menyajikannya ke mobile app atau web dengan satu query.

Saat kampanye flash sale: ribuan order masuk via REST eksternal, masing-masing memicu puluhan panggilan gRPC internal di antara microservices. GraphQL di BFF layer mengagregasi data untuk halaman order confirmation. Audit log dari seluruh interaksi ini yang akan kita bahas di Level 4.

---

6. Lensa Performance Tester

Tiga angka yang harus kamu tanyakan saat melihat pilihan protokol di design doc:

1. Payload ratio: Berapa byte yang dikirim vs berapa byte yang benar-benar dipakai? REST atau GraphQL yang buruk bisa memiliki rasio 10:1 — hanya 10% data yang relevan.

2. Connection overhead: Untuk gRPC, apakah connection pool sudah dikonfigurasi? Biaya setup HTTP/2 connection bukan nol, dan connection storm bisa terjadi di sini sama seperti di database (Sesi 16).

3. Resolver depth / join cost: Untuk GraphQL, minta tim menunjukkan query paling dalam di schema. Tiering query berdasarkan kedalaman dan batasi maksimum kedalaman query dari klien.

Skenario uji: - Load test endpoint REST dengan 1.000 VU mengambil resource yang sama — ukur payload size dan parsing time - Bandingkan latency gRPC vs REST untuk payload ukuran sama di 10.000 QPS - Di GraphQL, kirim query bersarang dalam yang melampaui 5 level — pastikan ada query complexity limiter yang menolak sebelum menyentuh database

---

7. Pertanyaan untuk Ronde Berikutnya

REST, gRPC, dan GraphQL menyelesaikan pertanyaan "dengan format apa" layanan saling bicara. Tapi ada pertanyaan berikutnya yang lebih penting: ketika satu layanan bertanya ke tiga layanan lain sekaligus, siapa yang bertanggung jawab memastikan bahwa kalau layanan keempat itu lambat — tidak ada yang ikut terseret?

Itulah yang dibahas di Sesi 24: Lalu Lintas Antar Layanan — Envoy, Service Mesh, dan Batas Kepercayaan.