Tim teknik masih menghabiskan seluruh sore berdebat apakah REST sudah mati atau apakah gRPC telah membuat segalanya usang. Perdebatan itu meleset dari intinya. Anda tidak sedang memilih protokol terbaik. Anda sedang memilih batasan (boundary) yang tepat. Protokol yang berjalan mulus di dalam klaster Kubernetes Anda akan terasa menyesakkan saat Anda menyerahkannya kepada ribuan pengembang eksternal. Protokol yang menghemat bandwidth berharga pada aplikasi seluler Anda akan membangkrutkan infrastruktur Anda jika Anda membukanya untuk kueri publik sembarangan. Perlakukan keputusan ini seperti kontes popularitas teknologi, dan Anda akan mengunci utang arsitektural yang bertahan lebih lama dari setiap anggota tim Anda saat ini.

Prinsip Batasan

Arsitektur adalah tentang trade-offs, bukan tentang siapa pemenangnya. Pertanyaan yang benar bukanlah "Mana yang tercepat?" atau "Mana yang terbaru?" Melainkan "Siapa yang berada di sisi lain kabel, dan apa yang mereka kendalikan?" Protokol adalah objek batasan. Memilih yang salah tidak hanya memperlambat Anda. Hal itu akan menanamkan kesalahan ke dalam sistem Anda selama bertahun-tahun.

API Publik: REST Tidak Membosankan, REST Bertanggung Jawab

Ketika konsumen Anda adalah pengembang eksternal yang belum pernah Anda temui, API Anda adalah sebuah produk, bukan sekadar antarmuka. Pengembang tersebut sedang melakukan debugging pada jam dua pagi hanya dengan curl dan koleksi Postman. Jika mereka harus menginstal pustaka klien khusus atau mempelajari bahasa skema sebelum panggilan pertama mereka berhasil, Anda sudah kehilangan mereka.

REST bertahan di sini karena ia adalah web itu sendiri. Metode HTTP, kode status, dan JSON adalah bahasa umum. Caching bukanlah pemikiran tambahan; itu adalah infrastruktur yang sudah ada. Browser, CDN, dan edge cache memahami header Cache-Control dan validasi ETag secara asli. Anda dapat menempatkan API REST di belakang CDN standar dan mendapatkan penghematan bandwidth secara instan tanpa menulis satu baris pun logika caching. Hal ini sangat penting ketika lalu lintas publik tidak dapat diprediksi dan Anda membayar untuk setiap gigabyte yang keluar dari cloud Anda.

Sebaliknya, GraphQL membawa "pajak" yang berat pada batasan publik. Endpoint GraphQL publik memerlukan analisis biaya kueri, pembatasan kedalaman (depth limiting), dan penilaian kompleksitas untuk mencegah satu kueri yang ceroboh atau berbahaya menghancurkan database Anda. Anda tidak hanya mengirimkan API; Anda sedang membangun mesin eksekusi kueri, strategi pembatasan laju (rate-limiting), dan model penagihan komputasi. Kecuali Anda memiliki kekuatan operasional seperti platform terbesar, beban overhead tersebut sangat berisiko untuk area permukaan publik. REST menetapkan guardrails secara default. Setiap endpoint melakukan satu hal. Konsumen mengambil tepat apa yang Anda tawarkan, bukan apa pun yang bisa mereka bayangkan.

Layanan Internal: Kuasai Seluruh Jalur

Di dalam organisasi Anda, percakapan berubah. Anda mengendalikan klien maupun server. Anda dapat mendikte tumpukan teknologi (technology stack) untuk setiap layanan dalam rantai panggilan. Di sinilah gRPC menunjukkan kegunaannya.

Pertama, berhentilah menganggap JSON sebagai sesuatu yang sakral. Protocol Buffers melakukan serialisasi sekitar tiga kali lebih cepat daripada JSON. Payload-nya lebih kecil karena formatnya biner. Pada jaringan internal yang sibuk, milidetik dan megabyte tersebut terakumulasi menjadi uang sungguhan dan menurunkan tail latency. Yang lebih penting, Protobuf memberi Anda kontrak yang ketat. Saat Anda mengubah tipe field atau mengganti nama pesan, kerusakan terjadi pada saat kompilasi (compile time), bukan pada jam tiga pagi di produksi saat layanan hilir (downstream service) mulai melempar pengecualian parsing.

gRPC berjalan di atas HTTP/2, sehingga Anda mendapatkan kompresi header, multiplexed streams, dan semantik streaming yang nyata. Jika Anda menyalurkan peristiwa (events) throughput tinggi antar layanan atau mendorong pembaruan real-time, server-side dan bidirectional streaming adalah fitur asli, bukan solusi sementara long-polling yang ditempelkan secara paksa pada kerangka kerja request-response.

Ada satu kendala besar: jangan arahkan gRPC langsung ke browser. Model jaringan browser tidak berbicara HTTP/2 seperti yang diharapkan gRPC. Anda akan berakhir dengan memasang grpc-web dan proxy seperti Envoy pada tumpukan Anda hanya agar browser dapat berbicara dengan backend. Itu bukan bug; itu adalah sinyal batasan. Simpan gRPC di balik firewall Anda, di antara layanan yang saling mempercayai satu sama lain, dan anggap kompleksitas debugging-nya sebagai harga dari kecepatan. Payload biner tidak mudah dibaca secara visual di file log seperti halnya JSON.

UI Kompleks dan Seluler: Niche GraphQL

Layar seluler modern adalah kumpulan potongan (patchworks). Satu tampilan mungkin memerlukan profil pengguna,