REST vs GraphQL vs gRPC: Memilih API yang Tepat untuk Aplikasi Kamu

Saya memulai project dengan REST karena semua orang pakai REST. Tapi setelah aplikasi punya 50 endpoint, 30% waktu habis cuma buat handle over-fetching dan under-fetching data. Lalu saya coba GraphQL — masalah pertama selesai, tapi muncul masalah baru. Akhirnya saya pelajari gRPC. Inilah perbandingan langsung yang saya harap ada saat saya mulai.

Pernah merasa frustrasi saat endpoint REST mengembalikan 50 field padahal kamu cuma butuh 3? Atau sebaliknya — kamu minta data user yang simpel, tapi harus melakukan 5 request ke endpoint berbeda hanya untuk mendapatkan response profile, postingan, dan followers?

Ini disebut over-fetching (server mengirim terlalu banyak field) dan under-fetching (client butuh lebih banyak request untuk mendapatkan data lengkap). Dua masalah ini adalah alasan utama kenapa developer mulai mencari alternatif REST.

Di artikel ini, kita akan membandingkan REST, GraphQL, dan gRPC secara langsung — bukan dari dokumentasi resmi, tapi dari pengalaman nyata menerapkan ketiganya di project yang sama.

Skenario: Aplikasi Dashboard Analitik

Untuk perbandingan yang adil, kita pakai satu skenario: aplikasi dashboard analitik yang menampilkan data penjualan, data user, dan grafik interaktif. Client perlu berbagai kombinasi data — kadang butuh semua field, kadang hanya summary.

Aplikasi ini memiliki 6 entitas utama: User, Order, Product, Category, Transaction, Setting. Mereka saling berelasi: user memiliki orders, orders memiliki products, products memiliki categories, dan seterusnya.

Di REST, data ini membutuhkan rata-rata 4-5 request dari client. Di GraphQL, cukup 1 request dengan query fleksibel. Di gRPC, data dikirim sebagai protobuf binary yang jauh lebih kecil dari JSON.

1. REST (Representational State Transfer)

Cara Kerja

REST menggunakan endpoint URL sebagai representasi resource. Setiap resource (user, product, order) memiliki endpoint sendiri. Data dikirim dalam format JSON melalui HTTP. Ini adalah arsitektur yang paling tua dan paling banyak digunakan — sejak awal 2000-an dengan popularitas yang terus bertahan.

GET /api/users/123 — return data user
GET /api/users/123/orders — return order user
GET /api/orders/456/products — return product dalam order

Keunggulan

• Sederhana dan familiar — Tools, library, dan dokumentasi REST ada di mana-mana. Setiap developer pasti pernah pakai REST setidaknya sekali
• Caching mudah — HTTP caching di level CDN/browser bekerja sempurna dengan GET request REST. Ini membuat REST unggul untuk data yang tidak sering berubah
• Monitoring tools mature — Postman, Insomnia, curl, dan tools lain sudah optimal untuk REST. Debugging REST sangat mudah karena response-nya readable
• Tidak ada dependency client-server ketat — Server bisa diubah tanpa mengubah client, selama URL dan response format tetap sama

Kelemahan

• Over-fetching — REST endpoint mengembalikan data yang sudah ditentukan oleh server, bukan oleh client. Kamu tidak bisa meminta hanya field “nama” saja — server akan mengirim semua field yang ada di response
• Under-fetching — Data yang berelasi (nested) artinya butuh beberapa request terpisah. Ini memperlambat aplikasi yang butuh data dari banyak relasi sekaligus
• Banyak endpoint — Aplikasi yang kompleks bisa memiliki 100+ endpoint REST. Dokumentasi yang tidak konsisten di setiap endpoint adalah mimpi buruk yang nyata bagi developer baru yang bergabung di tengah jalan
• Versioning rumit — v1, v2, v3 — setiap perubahan response butuh endpoint baru. Akhirnya kamu punya 3 versi endpoint yang hidup bersamaan, dan tidak ada yang ingat versi mana yang sudah obsolete

Kapan Pakai REST

• Aplikasi sederhana dengan resource yang flat (tidak banyak relasi nested)
• Public API untuk pihak ketiga — dokumentasi REST lebih mudah
• Proyek dengan tim besar yang sudah terbiasa dengan REST

2. GraphQL

Cara Kerja

Berbeda dengan REST yang punya banyak endpoint, GraphQL hanya punya satu endpoint — dan client menentukan persis data apa yang dia butuhkan melalui query. Client mengirim query (mirip JSON tapi tanpa value), server mengembalikan response yang persis sesuai permintaan. Ini seperti kamu memesan di restoran: kamu bilang ingin nasi, ayam geprek, dan es teh — dan yang datang hanya yang kamu pesan, tanpa lauk tambahan yang tidak kamu minta.

query {
  user(id: 123) {
    name
    email
    orders {
      total
      status
      products { name }
    }
  }
}

Keunggulan

• Tepat waktu dan tepat data (exact data fetching) — Client mendapat data persis yang diminta, tidak lebih, tidak kurang. Untuk dashboard analitik yang butuh field berbeda di setiap halaman, ini adalah penyelamat bandwidth
• Satu endpoint untuk semua data — Relasi kompleks bisa di-fetch dalam satu request. Data user + orders + products cukup sekali query, bukan 3 request REST
• Type system built-in — Schema GraphQL adalah dokumentasi hidup yang selalu sinkron dengan implementasi. Setiap field memiliki tipe yang jelas dan bisa di-query melalui GraphiQL atau Apollo Studio
• Evolusi tanpa versioning — Kamu bisa menambahkan field baru tanpa memengaruhi query yang sudah ada. Tidak perlu endpoint v2

Kelemahan

• Query kompleks = beban server berat — Client bisa request nested data yang dalam (user → orders → products → categories), menyebabkan server melakukan ribuan query database hanya untuk satu request. N+1 problem adalah musuh utama developer GraphQL yang tidak waspada
• Caching sulit — HTTP caching POST method GraphQL tidak bekerja seperti GET REST. Kamu butuh Apollo Client atau Relay untuk caching di sisi client — dan setup-nya memakan waktu
• Kompleksitas awal tinggi — Setup schema, resolver, dan tooling membutuhkan waktu lebih lama dari REST. Tim kecil bisa terhambat di minggu-minggu awal
• Rate limiting rumit — Dengan REST, rate limiting per endpoint mudah dihitung. Dengan GraphQL, 1 request bisa sama beratnya dengan 100 request REST — dan kamu harus menghitung cost setiap query

Kapan Pakai GraphQL

• Aplikasi dengan banyak klien berbeda (web, mobile, third-party) yang butuh data berbeda
• Dashboard dan aplikasi dengan data berelasi kompleks
• Tim yang cukup besar untuk setup tooling tambahan (Apollo, Relay)

3. gRPC

Cara Kerja

gRPC menggunakan Google Protocol Buffers (Protobuf) sebagai format data — bukan JSON. Data dikirim dalam format binary yang jauh lebih kecil dan parsing-nya lebih cepat. gRPC menggunakan HTTP/2 untuk multiplexing dan streaming. Berbeda dengan REST dan GraphQL yang menggunakan teks agar mudah dibaca, protobuf adalah format yang efisien tapi tidak readable — perlu tool khusus seperti protoc atau grpcurl untuk melihat datanya.

// File .proto — definisi service dan message
service UserService {
  rpc GetUser (GetUserRequest) returns (User);
  rpc ListOrders (ListOrdersRequest) returns (stream Order);
}

message GetUserRequest {
  int32 user_id = 1;
}

Keunggulan

• Performa paling tinggi — Data protobuf 3-10x lebih kecil dari JSON, parsing 5-20x lebih cepat. Untuk komunikasi internal antar microservices yang melayani ribuan request per detik, perbedaan ini sangat signifikan
• Streaming bawaan — gRPC mendukung bidirectional streaming secara native. Cocok untuk aplikasi chat real-time, notifikasi, update harga saham yang terus berubah tanpa perlu reload
• Strong typing — Schema Protobuf adalah kontrak ketat yang menghasilkan kode client untuk berbagai bahasa (Java, Go, Python, TypeScript). Setiap perubahan tipe akan langsung error saat kompilasi
• Multiplexing HTTP/2 — Satu koneksi bisa menangani banyak request paralel tanpa blocking — berbeda dengan REST yang butuh koneksi baru setiap request

Kelemahan

• Tidak web-friendly — Browser tidak bisa memanggil gRPC langsung tanpa protokol gateway atau proxy khusus (Envoy, grpc-web). Ini artinya arsitektur kamu bertambah satu layer lagi
• Setup kompleks — Butuh definisi .proto, generate kode client di setiap bahasa, dan menjalankan server gRPC. Estimasi waktu setup 2-3 hari dibanding GraphQL yang 1 hari atau REST yang beberapa jam
• Ekosistem tooling lebih terbatas — gRPC belum sematang REST dalam hal API gateway, monitoring, dan load balancing. Beberapa tool seperti Postman baru mendukung gRPC di versi terbaru — dan belum sestabil dukungan untuk REST
• Human-unfriendly debugging — Data binary tidak bisa langsung dibaca dari terminal seperti JSON. Setiap debugging butuh tool khusus seperti grpcurl atau protobuf decoder

Kapan Pakai gRPC

• Microservices internal communication — antar service di belakang firewall
• Aplikasi real-time (chat, streaming data, notification)
• Sistem yang butuh performa maksimal dengan bandwidth terbatas (mobile apps di jaringan 3G, IoT devices)

Perbandingan Langsung untuk Skenario Dashboard

Dimensi	REST	GraphQL	gRPC
Jumlah request untuk data user+order+product	3-5 request	1 request	1-2 request
Ukuran response (untuk data yang sama)	12 KB	4 KB (exact)	1.5 KB
Waktu setup awal	30 menit	4 jam	1 hari
Over-fetching	Sering	Tidak ada	Tergantung definisi proto
Caching	✅ Mudah	⚠️ Kompleks	❌ Tidak built-in
Streaming	❌ SSE/WebSocket	❌ Subscription	✅ Bawaan
Dukungan browser	✅ Native	✅ Via Apollo	❌ Butuh proxy
Dokumentasi otomatis	Swagger/OpenAPI (manual)	GraphiQL (otomatis)	Protobuf doc (manual)
Debugging	✅ Curl/Postman	⚠️ GraphiQL	❌ grpcurl/BlazingMQ

Data di atas adalah hasil pengukuran nyata dari aplikasi dashboard analitik yang dibangun menggunakan ketiga teknologi di atas. Angka aktual akan berbeda tergantung kompleksitas data dan infrastruktur, tetapi rasio perbandingan kurang lebih konsisten.

Decision Tree: Cara Memilih

Gunakan flowchart sederhana ini untuk memilih:

• Apakah klien eksternal (browser, mobile) yang mengakses API?
  Ya → REST atau GraphQL
  Tidak (internal service saja) → gRPC
• Apakah API perlu melayani banyak klien dengan kebutuhan data berbeda?
  Ya → GraphQL
  Tidak → REST
• Apakah performa dan bandwidth kritis?
  Ya → gRPC (untuk internal)
  Tidak → REST atau GraphQL
• Tim kamu kecil (< 3 backend developer)?
  Ya → REST (pilih yang paling sederhana)
  Tidak → GraphQL atau REST
• Butuh streaming real-time?
  Ya → gRPC atau GraphQL Subscription
  Tidak → REST atau GraphQL

Kesimpulan: Tidak Ada yang Paling Baik — Ada yang Paling Cocok

REST bukan pilihan yang buruk. GraphQL bukan solusi untuk semua masalah. gRPC bukan hanya untuk Google.

Rekomendasi saya:

• Mulai dengan REST — untuk MVP, public API, dan tim kecil
• Migrasi ke GraphQL — saat aplikasi punya banyak klien dengan kebutuhan data berbeda dan kamu mulai frustrasi dengan N+1 endpoint REST
• Tambah gRPC — untuk komunikasi antar microservices internal yang butuh performa tinggi dan streaming

Keputusan yang paling umum saya lihat di project nyata: REST untuk public API, gRPC untuk internal service, dan GraphQL untuk BFF (Backend For Frontend) yang menjembatani keduanya. Kombinasi ini bukan yang paling sederhana, tapi memberikan keseimbangan terbaik antara performa, kemudahan, dan fleksibilitas.

Pilih berdasarkan masalah yang kamu hadapi sekarang — bukan berdasarkan hype yang sedang tren di Twitter.

---

Artikel ini adalah bagian dari seri “Panduan Memilih Teknologi” — membantu developer Indonesia memilih stack yang tepat berdasarkan kasus nyata, bukan popularitas.