gRPC: Gambaran Komunikasi Super Cepat antar Server

Telepon langsung vs surat-menyurat

REST berkomunikasi seperti surat: teks JSON yang mudah dibaca tapi boros tempat. gRPC seperti telepon langsung: percakapan biner yang padat dan cepat, dengan "operator" yang memastikan kedua pihak bicara bahasa yang sama (contract via file .proto). Ini adalah standar komunikasi antar microservice di perusahaan besar.

Kenapa gRPC lahir

Di arsitektur microservice, puluhan layanan saling memanggil ribuan kali per detik. Overhead JSON (teks, besar, harus di-parse) menjadi mahal. gRPC memakai Protocol Buffers: format biner yang 5-10x lebih kecil dan cepat, plus berjalan di atas HTTP/2 (multiplexing, kompresi header). Hasilnya latensi jauh lebih rendah untuk komunikasi internal.

Contoh 1: definisi service dalam .proto

syntax = "proto3";

service Kasir {
  rpc HitungTotal (Keranjang) returns (Total);
}

message Keranjang {
  repeated Item items = 1;
}

message Item {
  string nama = 1;
  int32 harga = 2;
}

message Total {
  int32 jumlah = 1;
}

Satu file ini adalah kontrak: nama service, method, dan struktur datanya. Dari file ini di-generate kode klien dan server dalam 10+ bahasa, semua type-safe.

Contoh 2: kapan pakai, kapan tidak

Pakai gRPC untuk: komunikasi internal microservice, aplikasi real-time yang butuh latensi rendah, dan polyglot environment (Go, Java, Python saling bicara). Jangan pakai untuk: API publik yang dikonsumsi browser (browser tidak bicara gRPC native, butuh proxy gRPC-Web), dan tim kecil dengan satu-dua service (overhead setup tidak sepadan).

Kesalahan umum

Salah: memaksa gRPC untuk API publik web. Browser butuh gRPC-Web + proxy Envoy, menambah kompleksitas. Yang benar: API publik tetap REST/JSON atau GraphQL.

Salah: tidak memikirkan versioning proto. Mengubah nomor field sembarangan merusak kompatibilitas. Yang benar: ikuti aturan proto (jangan ubah nomor field yang ada, tambah field baru dengan nomor baru).

Salah: mengabaikan observability. Komunikasi biner sulit diintip dibanding JSON. Yang benar: siapkan tracing (OpenTelemetry) dan logging sejak awal.

Kapan gRPC overkill

Tanda-tanda kamu belum butuh gRPC:

1. Hanya punya 1-2 service yang jarang bicara.
2. Tim kecil yang belum familiar dengan protobuf.
3. API dikonsumsi langsung oleh browser.
4. Butuh debugging cepat dengan curl/Postman (biner sulit diintip).

Untuk kasus-kasus ini, REST + JSON tetap raja: mudah ditulis, mudah dibaca, mudah di-debug. gRPC bersinar saat skala sudah besar: puluhan service, ribuan request per detik, tim polyglot. Adopsi teknologi mengikuti masalah, bukan tren.

Catatan teknis: gRPC mendukung 4 pola: unary (request-response biasa), server streaming, client streaming, dan bidirectional streaming. Streaming dua arah inilah yang membuatnya cocok untuk chat dan data real-time antar service.