Belajar gRPC - Sejarah, Latar Belakang & Mengapa Membutuhkan gRPC

#Pendahuluan

Setiap teknologi besar lahir dari masalah nyata, dan gRPC tidak terkecuali. Episode 1 menceritakan mengapa gRPC ada: bagaimana Google berjuang menghubungkan jutaan service internal, lahirnya Stubby sebagai solusi, dan bagaimana gRPC dikembangkan ulang sebagai proyek open source untuk dunia.

Di episode ini kalian akan memahami perjalanan sejarah, posisi Protocol Buffers sebagai bahasa kontrak default, dan yang paling penting: kapan gRPC unggul dibanding REST/JSON serta kapan sebaiknya dihindari. Pemahaman ini menentukan keputusan arsitektur di seluruh sisa series.

Kami juga menyinggung konteks industri: mengapa raksasa teknologi memilih gRPC, dan bagaimana keputusan tersebut bisa atau tidak bisa diterapkan di project kalian.

#Evolusi dari Stubby ke gRPC

#Kelahiran di Google

Pada awal 2000-an, Google menjalankan ribuan service di dalam satu datacenter yang harus saling berkomunikasi. Solusinya adalah Stubby, framework RPC internal yang menangani triliunan panggilan per hari. Stubby memakai protobuf sebagai format data dan mendukung fitur seperti timeout, retry, dan load balancing.

Masalahnya: Stubby terikat erat dengan infrastruktur internal Google. Tidak ada dokumentasi publik, tidak ada versi yang bisa diinstall, dan tidak dirancang untuk internet publik. Ketika ekosistem eksternal mulai memakai protobuf lewat rilis open source Protocol Buffers, jelas bahwa framework komunikasinya pun perlu dibuka.

#Rilis Open Source dan CNCF

gRPC diumumkan sebagai open source pada Maret 2015 dan mencapai versi stabil 1.0 pada Agustus 2016. Tiga pilihan desain kunci membedakannya dari Stubby:

• Transport memakai HTTP/2, bukan protokol privat, sehingga bisa lewat infrastruktur internet standar.
• Mendukung banyak bahasa sejak awal: Go, Java, C++, Python, Node.js, dan lainnya.
• Kontrak ditulis dalam protobuf versi 3 yang disederhanakan agar ramah bagi developer baru.

Pada 2017 gRPC didonasikan ke Cloud Native Computing Foundation (CNCF), bergabung dengan Kubernetes dan Prometheus. Adopsi lintas industri berkembang pesat — dari Netflix dan Dropbox sampai platform cloud besar. gRPC kini juga menjadi transport default untuk banyak sistem observability dan service mesh.

Perkembangan ini terus berlanjut sampai rilis stabil terbaru: fitur seperti server reflection, health checking standar, dan dukungan xDS untuk load balancing dinamis hadir secara bertahap. Untuk memeriksa versi gRPC yang terpasang di sebuah project Go, kalian bisa membuka go.mod dan menjalankan go list -m google.golang.org/grpc untuk melihat versi persis yang digunakan.

Pola yang bisa kalian amati dari sejarah ini: gRPC selalu berkembang dari kebutuhan nyata, bukan sekadar mengejar tren. Setiap fitur utama yang kita pakai di series ini — streaming, metadata, reflection, health check — muncul karena ada masalah konkret yang harus diselesaikan, bukan karena terdengar keren di atas kertas.

#Protocol Buffers sebagai IDL Default

Pilihan menjadikan protobuf sebagai IDL (Interface Definition Language) adalah keputusan arsitektur paling berpengaruh. Sebuah file .proto mendeskripsikan data dan service secara deklaratif:

syntax = "proto3";
 
message Item {
  string id = 1;
  string name = 2;
}
 
service Catalog {
  rpc GetItem(Item) returns (Item);
}

Kontrak di atas dibaca oleh compiler protoc dan membangkitkan kode di semua bahasa target. Dengan model schema-first ini, client dan server tidak bisa mengarang kontrak: apa yang tidak ada di .proto tidak bisa dipanggil. Perintah protoc untuk membangkitkan kode adalah salah satu yang akan kita pakai sejak episode 4.

Sebelum melanjutkan, pastikan compiler protobuf sudah terpasang di sistem kalian dengan menjalankan protoc --version. Output seperti libprotoc 3.21.x menandakan lingkungan siap — ini verifikasi yang sama yang kalian lakukan di episode 0.

#gRPC vs REST/JSON

#Performa dan Ukuran Payload

Perbedaan paling kasat mata: REST biasanya memakai JSON berbasis teks, sedangkan gRPC memakai protobuf biner. Bayangkan mengirim data yang sama lewat dua jalan yang berbeda:

curl -X POST http://localhost:8080/items \
  -H "Content-Type: application/json" \
  -d '{"id":"a1","name":"Kursi"}'

versus panggilan gRPC yang ukurannya jauh lebih kecil karena data diserialisasi ke biner dan header HTTP/2 dikompresi. Untuk payload besar dan lalu lintas tinggi, penghematan bandwidth ini langsung terasa di biaya dan latensi.

Perbandingan singkatnya begini: untuk memanggil endpoint yang sama, curl -X POST http://localhost:8080/items -d '{...}' mengirim teks JSON plus header teks, sementara panggilan gRPC mengirim protobuf biner plus header terkompresi HPACK. Semakin sering dipanggil, semakin besar selisihnya.

#Strongly-Typed dan Schema-First

Di REST, request dan response divalidasi manual di kedua sisi; typo nama field baru ketahuan saat runtime. Di gRPC, kontrak .proto memaksa tipe data pada compile time — kesalahan terdeteksi jauh lebih awal. Kolaborasi lintas tim juga lebih mudah karena .proto menjadi satu sumber kebenaran yang sama untuk semua bahasa.

#Streaming dan Contract-Driven Development

gRPC menyediakan empat pola komunikasi — unary, server streaming, client streaming, dan bidirectional streaming — semuanya di atas satu koneksi HTTP/2. REST pada dasarnya satu request satu response, jadi real-time streaming memerlukan solusi tambahan seperti WebSocket. Untuk microservices yang butuh komunikasi streaming, observability bawaan, dan kontrak yang teruji, gRPC adalah pilihan natural.

Sisi lain yang jarang dibahas: dengan kontrak yang dibangkitkan ke banyak bahasa, tim backend dan frontend berbagi definisi yang sama tanpa bolak-balik memperbaiki dokumentasi. Perubahan field yang merusak client langsung terlihat di compile time, bukan setelah user melapor. Inilah nilai contract-driven development yang nanti kalian rasakan penuh di episode 8 tentang schema evolution.

#Kapan gRPC Bukan Pilihan Tepat

Tidak ada solusi yang sempurna untuk semua kasus. Hindari gRPC ketika:

• Aplikasi browser langsung: browser tidak bisa mengirim request gRPC mentah tanpa perantara seperti Envoy atau gRPC-Web (episode 16).
• Public API untuk konsumen eksternal: JSON dan REST lebih universal, mudah di-debug dari browser, dan didukung setiap tooling.
• Ekosistem yang sudah kuat berbasis HTTP: bila seluruh sistem sudah memakai REST/OpenAPI, menambah gRPC berarti mengelola dua stack sekaligus.
• Kebutuhan sangat sederhana: satu endpoint kecil dengan traffic rendah tidak akan merasakan keunggulan gRPC, tapi tetap menanggung kompleksitas protobuf.

Kasus yang sering luput: gRPC juga kurang cocok untuk konsumen dengan bandwidth sangat terbatas yang hanya butuh satu data kecil, atau untuk sistem yang memerlukan cache HTTP level infrastruktur. REST dengan semantic GET yang benar bisa memanfaatkan CDN dan reverse-proxy caching, sedangkan gRPC unary tidak memanfaatkannya secara natural. Pertimbangkan faktor ini saat mendesain API untuk skala publik.

Prinsipnya: gRPC unggul di internal service-to-service dengan traffic tinggi dan kebutuhan streaming; REST tetap juara untuk edge API yang menghadap publik.

Sebagai pedoman praktis saat memilih: tanyakan dulu siapa konsumennya. Kalau konsumennya service lain di dalam sistem kalian dan lalu lintasnya tinggi, pilih gRPC. Kalau konsumennya browser, aplikasi pihak ketiga, atau partner eksternal, pilih REST dengan JSON dan dokumentasikan lewat OpenAPI. Keputusan ini sebaiknya diambil per API, bukan dipaksakan sama untuk seluruh sistem.

Perlu juga diingat bahwa kedua teknologi tidak harus bersaing — banyak arsitektur production memakai keduanya sekaligus. Service internal bicara gRPC, dan di depan mereka berdiri gateway yang menerjemahkan ke REST untuk publik (episode 16). Dengan pola ini, keunggulan performa gRPC dan universalitas REST bisa dinikmati dalam satu sistem.

#Penutup

Inti yang harus dibawa pulang:

• gRPC berevolusi dari Stubby, framework RPC internal Google, lalu dirilis open source tahun 2015.
• Protobuf sebagai IDL memberi gRPC skema kuat, payload biner kecil, dan code generation lintas bahasa.
• gRPC unggul di performa, strongly-typed contract, dan streaming dibanding REST/JSON.
• gRPC bukan pilihan tepat untuk browser publik atau API eksternal tanpa gateway.
• Keputusan gRPC versus REST adalah keputusan arsitektur, bukan sekadar preferensi teknologi.

Di episode 2 selanjutnya kita akan membedah konsep dasar dan arsitektur utama gRPC — bagaimana protobuf diubah menjadi kode client dan server, peran HTTP/2 multiplexing dan HPACK, komponen stub dan channel, serta metadata, deadline, dan status code yang mengatur siklus hidup setiap RPC. Siapkan kontrak .proto di kepala kalian, karena fondasi arsitektur inilah yang dipakai semua episode berikutnya.