REST API vs gRPC: Kapan Sebaiknya Mulai Pindah dari JSON?

Hampir semua dari kita memulai perjalanan backend dengan bikin REST API berbasis JSON. Nggak ada yang salah, kok. Formatnya human-readable, gampang dites pakai Postman atau cURL, dan hampir semua bahasa pemrograman di muka bumi ini ngerti. Kita tinggal nembak endpoint-nya, terus terima JSON. Simpel, kan?

Tapi begitu sistem kalian berubah jadi arsitektur microservices—puluhan bahkan ratusan service internal yang saling tuker data jutaan kali per detik—overhead JSON dan HTTP/1.1 mulai kerasa. Emang iya? Iya. 😅

Di situ gRPC (Google Remote Procedure Call) masuk jadi alternatif bertenaga buat komunikasi antar-service internal. Yuk, kita bedah bareng-bareng!

Kenapa REST API dengan JSON Begitu Populer?

REST API dengan JSON menguasai industri perangkat lunak bukan tanpa alasan, lho:

1. Sangat mudah dibaca. Data berupa teks biasa kayak {"nama": "Inva", "role": "Developer"} langsung kebaca tanpa perlu dekoder khusus.
2. Fleksibel dan dinamis. Nggak perlu skema kaku di level protokol transport.
3. Standar browser. Web browser secara native ramah banget ngonsumsi payload JSON.

Format teks ini udah kayak bahasa ibu buat frontend developer. Buka DevTools, lihat tab Network, semua data langsung kebaca mata telanjang. Nggak perlu alat tambahan apa-apa.

Keterbatasan REST & JSON di Skala Mikroservis

Ramah buat developer belum tentu ramah buat server, nih. Begitu trafik internal melonjak, kombinasi REST + JSON mulai nunjukin gigi aslinya:

• Ukuran payload besar. JSON bawa banyak karakter redundan: spasi, kurung kurawal, kutip ganda, plus nama field kayak "nama_lengkap" yang diulang di setiap item list.
• Proses parsing lambat. Ngubah string JSON jadi objek memori di Python, Java, atau Go makan siklus CPU yang lumayan.
• HTTP/1.1 yang ketinggalan zaman. REST API tradisional secara default pakai HTTP/1.1 yang rentan head-of-line blocking dan nggak support multiplexing murni dalam satu koneksi TCP.

Anggap aja kalian ngirim paket pakai kurir yang motornya cuma bisa bawa satu kardus sekali jalan. Buat kiriman sebulan sekali, ya aman-aman aja. Buat kiriman tiap detik, repot. 😂

Mengenal gRPC: Apa Itu dan Gimana Cara Kerjanya?

gRPC itu framework open-source buatan Google buat komunikasi Remote Procedure Call (RPC). Dengan gRPC, sebuah service bisa manggil fungsi di service lain kayak fungsi itu ada di program lokalnya sendiri.

Ada dua pilar utama yang bikin gRPC kencang:

1. HTTP/2. Koneksi persisten tunggal dengan multiplexing—banyak request/response jalan barengan di satu koneksi TCP—plus kompresi header dan streaming dua arah (bidirectional).
2. Protocol Buffers (Protobuf). Mekanisme serialisasi data biner dengan skema ketat (strongly typed) yang jauh lebih kecil dan cepat ketimbang JSON.

Protocol Buffers vs JSON: Kok Bisa Lebih Ringkas?

Dengan Protobuf, kalian mendefinisikan skema kontrak komunikasi di file .proto:

syntax = "proto3";

package user;

message UserRequest {
  int32 id = 1;
}

message UserResponse {
  int32 id = 1;
  string name = 2;
  string email = 3;
}

service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
}

Nah, pas data dikirim lewat jaringan, Protobuf nggak ngirim nama field kayak "name" atau "email". Yang dikirim cuma nomor tag biner (1, 2, 3) dan nilainya dalam bentuk binary stream.

Hasilnya lumayan gila:

• Ukuran data bisa 3x sampai 10x lebih kecil ketimbang JSON.
• Proses serialisasi/deserialisasi bisa 5x sampai 8x lebih cepat karena diproses langsung di level biner.

Buat satu request, bedanya mungkin nggak kerasa. Buat sejuta request per detik, selisihnya jadi tagihan cloud yang beda tipis-tipis. 🤔

Surat Pos vs Sinyal Telegram

Biar gampang kebayang:

• REST + JSON itu kayak ngirim surat kertas bertulis tangan lengkap dengan kop surat dan perangko. Penerima bisa langsung baca isinya pakai mata telanjang, tapi ongkos kirim dan waktu lipatnya makan tempat di ransel pak pos.
• gRPC + Protobuf itu kayak ngirim kode telegraf biner terkompresi lewat kabel fiber khusus. Manusia nggak bisa baca langsung tanpa mesin penerjemah, tapi transmisi dan decoding-nya secepat kilat.

Yang pertama cocok buat surat cinta. Yang kedua cocok buat ngirim data bursa saham tiap milidetik. Dua-duanya butuh, cuma beda medan perang aja. 😎

Kapan Pakai REST, Kapan Pakai gRPC?

Kalau diliat dari tabel di atas, polanya jelas: ke luar pakai REST, ke dalam pakai gRPC. Frontend dan mobile app nggak perlu nge-import .proto, mereka udah nyaman sama JSON. Nah, kalau butuh streaming dua arah, gRPC ngasih itu tanpa alat tambahan, lho.

Jadi, Waktunya Migrasi ke gRPC?

REST API dan JSON jelas belum bakal punah dalam waktu dekat. Keduanya masih jadi standar emas buat public API dan antarmuka pengguna (frontend web dan mobile).

Tapi begitu arsitektur sistem kalian berubah jadi ekosistem microservices yang tuker data jutaan kali per detik, pindah ke gRPC dan Protocol Buffers jadi jurus strategis. Network latency kepangkas, bandwidth kehemat, dan CPU server tetap adem.

Mulai dari satu service internal dulu deh. Nggak perlu migrasi total dalam semalam—migration yang jalan pelan tapi pasti biasanya lebih awet ketimbang rewrite besar-besaran. 😄

Selamat ber-arsitektur ria, dan semoga latency kalian selalu di bawah satu milidetik! 👋