Apa itu gRPC?

RPC, atau panggilan prosedur jarak jauh, adalah model komunikasi untuk interaksi klien/server yang memungkinkan panggilan jarak jauh muncul dan berfungsi sebagai panggilan lokal. Ini adalah teknik yang lebih tua, yang konsepnya sudah ada sejak tahun 1970-an, dengan aplikasi awal terlihat pada berbagai proyek komputasi perintis seperti ARPANET dan Xerox PARC.

Di RPC, klien berinteraksi dengan representasi server yang seolah-olah lokal tetapi sebenarnya merupakan perantara. Perantara ini biasanya disebut sebagai stub yang menangani data marshalling dan unmarshalling (yaitu mengonversi data ke dalam format yang sesuai untuk transmisi dan mengonversi hasil yang diterima dari server kembali ke format aslinya). Karena ini adalah gaya arsitektur untuk komunikasi klien/server, biasanya digunakan dalam desain API.

Ada banyak implementasi kerangka kerja RPC yang berbeda, termasuk XML-RPC dan JSON-RPC. Implementasi ini menggunakan HTTP sebagai protokol transportasi mereka, sebagian besar berbeda dalam jenis format. Sejak tahun 1990-an dan 2000-an, implementasi ini memamerkan kekuatan RPC: mereka menyederhanakan pengembangan, kompleksitas komunikasi jaringan abstrak, ringan, relatif mudah digunakan, dan dapat dibaca manusia.

Namun, banyak lingkungan modern—terutama yang menggunakan arsitektur layanan mikro, lingkungan poliglot, dan sistem dengan beban data tinggi—memerlukan kerangka kerja yang lebih cepat dan berkinerja tinggi untuk menghubungkan aplikasi terdistribusi. Idealnya, kerangka kerja ini memfasilitasi transfer data real-time yang lebih efisien antara layanan yang berjalan di berbagai lingkungan dan pusat data.

gRPC dikembangkan untuk memenuhi kebutuhan ini, menawarkan latensi rendah dan throughput tinggi melalui serialisasi data dan penggunaan protokol HTTP/2, kemampuan streaming dua arah, pembuatan kode, dan banyak lagi.

GRPC awalnya dirilis pada tahun 2015 berbarengan dengan tahun rilis HTTP/2. Kerangka kerja ini mengatasi keterbatasan dengan implementasi RPC yang lebih lama, terutama melalui penggunaan Protocol Buffer, atau Protobuf, bahasa definisi antarmuka (IDL). Protobuf membuat serialisasi dan mengodekan data terstruktur menjadi biner. Hal ini menjadikan data lebih kompak, memungkinkan transmisi lebih cepat dan kinerja yang lebih tinggi.

Protobuf juga memungkinkan perubahan bidang data tanpa mengganggu kode. Ini membantu mengurangi kesalahan dan memungkinkan berbagi dan pemrosesan data secara real-time. Semua fitur ini menjadikan API yang dibangun dengan gRPC pilihan yang kuat untuk lingkungan modern dan terdistribusi, arsitektur layanan mikro, aplikasi streaming, dan untuk menghubungkan sistem dan perangkat Internet of Things.

Masuk akal jika gRPC adalah singkatan dari “Google Remote Procedure Call.” Nyatanya, tim gRPC di grpc.io dengan berani mengklaim bahwa itu adalah singkatan dari “gRPC Remote Procedure Call.” GitHub kerangka kerja ini mencatat bahwa "g" adalah singkatan dari sesuatu yang berbeda pada setiap versi (mulai dari "gregarious" dan "goose" hingga "Guadalupe River Park Conservancy"). Bagaimanapun, Google mengembangkan gRPC dan dirilis sebagai proyek sumber terbuka pada tahun 2015.

gRPC menyajikan versi RPC yang modern dan diperbarui, dengan dukungan untuk berbagai bahasa modern serta fitur tambahan dan optimasi. Fitur mencakup:

• Bahasa desain antarmuka (IDL) yang disebut Protocol Buffers
• Penggunaan HTTP/2 untuk transmisi data
• Streaming dua arah
• Pembuatan kode
• Empat jenis metode
• Integrasi dengan keamanan berbasis TLS
• Dukungan pencegat untuk pencatatan, pelacakan, autentikasi, dan lainnya

Protocol Buffer, dikenal luas sebagai Protobuf, adalah format data lintas platform yang dikembangkan oleh Google yang digunakan untuk melakukan serialisasi data terstruktur. Pada dasarnya, protokol ini berfungsi sebagai perantara yang kuat antara klien dan server yang melakukan serialisasi pada permintaan menjadi kode biner untuk transmisi.

Mekanisme ini fleksibel dan efisien, memungkinkannya tidak bergantung pada bahasa pemrograman tertentu, ukuran pesan yang lebih kecil, serta penguraian dan transmisi berbarengan yang lebih cepat. Aplikasi yang menggunakan Java dapat berkomunikasi dengan aplikasi yang menggunakan Python karena permintaan diubah menjadi lingua franca dari biner. Meskipun tidak dapat dibaca oleh manusia, biner lebih cepat untuk dikirim dan diuraikan oleh komputer daripada format berbasis teks seperti JSON.

Pada dasarnya, pengembang membuat file teks dengan akhiran ".proto" yang berisi semua informasi tentang struktur data. Informasi ini berbasis skema yang berarti bahwa informasi ini menetapkan parameter, metode, dan kemungkinan output—deskripsi struktur data. Misalnya, Anda mungkin memiliki entri untuk “pengguna,” yang mencatat bahwa data ini akan mencakup “nama,” “alamat email,” dan “taburan atas piza favorit.”

Menurut dokumentasi Protobuf, ini seperti XML, "tetapi lebih kecil, lebih cepat, dan lebih sederhana. Anda menentukan bagaimana data harus terstruktur satu kali, kemudian Anda dapat menggunakan kode sumber yang dibuat secara khusus untuk dengan mudah menulis dan membaca data terstruktur Anda ke dan dari berbagai aliran data dan menggunakan berbagai bahasa." Sebagai perantara, Protobuf memungkinkan instalasi berbagai autentikasi dan juga langkah keamanan.

Pengembang dapat menggunakan compiler yang disebut Protoc untuk menghasilkan kode dalam salah satu dari beberapa bahasa yang didukung, termasuk C#, C++, Dart, Go, Java, Kotlin, Node.js, Objective-C, PHP, Python, dan Ruby. Kode ini memiliki banyak fungsi: biasanya mencakup kelas atau modul, menangani serialisasi menjadi biner dan mengonversi serialisasi dari biner dan menyembunyikan kompleksitas pertukaran data. Pengembang tidak perlu mengkhawatirkan pengemasan jaringan, marshalling, pembaruan untuk kompatibilitas dan implementasi; Protobuf menangani semuanya.

Desain berbasis skema Protobuf memungkinkan pengembang untuk menambahkan bidang data baru ke struktur yang sudah ada tanpa merusak seluruh sistem. Hal ini juga sangat mengurangi upaya yang diperlukan untuk memperbarui, memelihara, dan menangani tugas-tugas terkait API yang membosankan, seperti menyesuaikan kode sebelumnya setelah menambahkan bidang data baru. Itu berarti pengaturan file .proto pada awalnya dapat memakan waktu dan upaya.

HTTP/2 adalah protokol transportasi—metode yang digunakan komputer dan server untuk bertukar informasi—yang menggunakan format biner untuk mengirim pesan, mengurangi koneksi TCP, dan menggunakan kompresi header, yang semuanya membantu membuatnya lebih cepat dan lebih efisien dibandingkan pendahulunya (HTTP/1.1). Protokol ini juga memungkinkan multiplexing, atau kemampuan untuk mengirim beberapa aliran bersamaan pada satu koneksi; gRPC menggunakan apa yang disebut saluran untuk memungkinkan beberapa aliran melewati beberapa koneksi tersebut. Pesan dikirim sebagai kerangka data HTTP/2 yang masing-masing mungkin berisi beberapa pesan gRPC.

gRPC menawarkan streaming dua arah, di mana klien dan server dapat secara independen mengirim pesan dalam aliran baca/tulis. Metode ini memungkinkan semua jenis fleksibilitas: server dan klien dapat bertukar respons secara berurutan, atau server dapat menunggu sampai semua pesan klien diterima sebelum merespons. Fitur ini dapat disesuaikan menurut aplikasi tertentu.

gRPC menggunakan alat kompiler yang disebut protoc untuk secara otomatis menghasilkan kode klien dan server dalam berbagai bahasa berdasarkan definisi layanan dan struktur pesan yang didefinisikan dalam file .proto . Plug-in dapat digunakan untuk memperluas dukungan ke lebih banyak bahasa.

Protoc menghasilkan kelas akses data dalam bahasa yang ditentukan dalam definisi proto. Kelas ini menyediakan pengakses sederhana untuk bidang seperti [nama], serta metode untuk serialisasi dan penguraian struktur ke dan dari byte mentah.¹

gRPC mendukung empat jenis metode berbeda untuk transmisi data: Unary, streaming sisi klien, streaming sisi server, dan streaming dua arah.

gRPC memiliki integrasi bawaan dengan TLS (keamanan lapisan transportasi), yang mengenkripsi pertukaran data antara klien dan server dan memungkinkan pengguna untuk membantu mengamankan koneksi.

gRPC mendukung autentikasi terpusat, pelacakan, pencatatan, metrik, penyeimbangan beban, pemeriksaan kesehatan, dan banyak lagi. 

gRPC memiliki empat jenis metode berbeda yang menunjukkan bagaimana pesan dikirim dan diterima oleh klien dan server gRPC. Jenis metode:

Unary: Panggilan sederhana di mana klien mengirimkan satu permintaan dan server membalas dengan satu respons.

Streaming sisi server: Panggilan di mana klien mengirimkan satu permintaan, tetapi server membalas dengan beberapa respons.

Streaming sisi klien: Panggilan di mana klien mengirimkan beberapa permintaan dan server membalas dengan satu respons. Server dapat memilih untuk menunggu seluruh aliran permintaan klien berhenti sebelum memproses dan merespons.

Streaming dua arah: Klien dan server mengirim beberapa panggilan bolak-balik secara bersamaan, sehingga memungkinkan komunikasi real-time.

Baik gRPC maupun REST adalah gaya arsitektur yang biasa digunakan dalam desain API. Keduanya memiliki banyak kesamaan; keduanya mengikuti arsitektur klien/server, bergantung pada komunikasi berbasis HTTP, tidak menyimpan status, dan tidak bergantung pada bahasa. Tetapi mereka juga memiliki cara utama yang berbeda sehingga masing-masing ideal untuk contoh penggunaan berbeda.

Format data: REST API menggunakan format teks biasa seperti JSON dan XML. gRPC menggunakan Protobuf untuk mengodekan data menjadi biner.

Pola komunikasi: gRPC mendukung empat metode: unary, streaming server, streaming klien, dan streaming dua arah. REST menggunakan sistem permintaan dan respons unary.

Pembuatan kode: gRPC menawarkan pembuatan kode bawaan, sementara REST tidak, meskipun ada plug-in yang tersedia.

Pola desain: gRPC memiliki desain berorientasi layanan, di mana operasi server yang dapat dipanggil ditentukan sebagai layanan atau fungsi. Dalam REST, desain berorientasi pada sumber daya, di mana metode HTTP digunakan untuk mengakses sumber daya server melalui titik akhir yang ditentukan oleh URL.

Protokol: gRPC menggunakan HTTP/2, sedangkan REST mengandalkan HTTP/1.1.

Keterikatan: Klien dan server gRPC saling terhubung erat, artinya klien dan server harus memiliki akses ke file proto middleware yang sama. Perubahan apa pun pada salah satu dari keduanya memerlukan perubahan pada yang lainnya. REST terikat secara longgar. Kemandirian ini berarti bahwa perubahan pada satu komponen tidak memengaruhi komponen lainnya.

gRPC sering digunakan untuk API kompleks yang menghubungkan beberapa layanan di lingkungan terdistribusi. Kemampuan streaming real-time dan kinerja tinggi membuat gRPC cocok untuk beberapa contoh penggunaan termasuk layanan mikro, streaming, dan menghubungkan klien Internet of Things.

Karena kinerja tinggi, latensi rendah, kemampuan untuk menangani volume data besar, dan kemampuan streaming dua arah secara real-time, gRPC sering digunakan untuk membuat API untuk layanan mikro.

Karena gRPC tidak bergantung pada bahasa, gRPC dapat memungkinkan komunikasi antara layanan yang ditulis dalam bahasa pemrograman berbeda. Selain itu, definisi Protobuf menyediakan jenis skema kuat yang membantu menjaga integritas data layanan mikro.

Kemampuan streaming dua arah gRPC berarti bahwa gRPC dapat melakukan streaming data secara bersamaan di kedua arah antara klien dan server melalui koneksi jaringan tunggal. Kemampuan ini membuat gRPC ideal untuk proses yang sedang berlangsung seperti konferensi video atau ketika pengguna ingin menggunakan bagian dari kumpulan data saat data lain sedang ditransfer.

Internet of Things mengacu pada jaringan perangkat atau klien yang terhubung. Perangkat IoT—dikenal juga sebagai “benda pintar”—dapat mencakup perangkat “rumah pintar” sederhana seperti termostat pintar, wearable seperti jam tangan pintar, dan pakaian berkemampuan RFID, serta mesin industri yang kompleks dan sistem transportasi.² API gRPC sering digunakan untuk memfasilitasi pertukaran data yang konsisten di antara semua perangkat ini.

Dengan dukungan streaming dua arah dan kemampuan ramah layanan mikro (dan statusnya sebagai proyek CNCF), gRPC semakin banyak digunakan untuk API cloud native.

gRPC digunakan untuk menghasilkan pustaka klien dalam banyak bahasa pemrograman yang berbeda. Pustaka ini dihasilkan berdasarkan definisi layanan yang disediakan di file .proto; setelah layanan ditentukan, gRPC secara otomatis menghasilkan kode klien dalam bahasa pemrograman yang dipilih.

Kemampuan ini menyederhanakan pekerjaan bagi para pengembang, memungkinkan mereka untuk berfokus pada logika aplikasi daripada kode komunikasi tingkat rendah.

gRPC menawarkan banyak manfaat bagi organisasi dan pengembang yang membangun API dengan persyaratan kinerja tinggi. Manfaatnya meliputi:

Transmisi yang lebih cepat dan lebih efisien: Ada beberapa faktor yang berkontribusi terhadap kinerja tinggi gRPC. Pertama, serialisasi Protobuf mengurangi ukuran pesan dan paket yang lebih kecil dapat ditransmisikan lebih cepat. Penguraian biner juga lebih efisien daripada format teks biasa seperti JSON atau XML.

Selain itu, gRPC menggunakan HTTP/2 yang lebih cepat dan lebih efisien daripada HTTP/1.1, mengurangi latensi dan penggunaan bandwidth lebih lanjut.

Portabilitas yang lebih besar: Karena gRPC menggunakan buffer protokol (mekanisme serialisasi yang tidak bergantung pada bahasa dan platform) untuk mendeskripsikan struktur data dan antarmuka RPC, gRPC dapat digunakan untuk memungkinkan komunikasi antara layanan yang ditulis dalam berbagai bahasa di platform berbeda.

Mengurangi kesalahan waktu proses: Protobuf menyediakan tipe kuat yang berarti bahwa mekanisme ini menerapkan struktur data yang kokoh dan didefinisikan secara eksplisit. Tipe yang kuat meningkatkan konsistensi dan deteksi kesalahan lebih awal, mengurangi kemungkinan kesalahan saat waktu proses.

Kustomisasi yang fleksibel: Dukungan bawaan untuk middleware memungkinkan penyesuaian dan penambahan fitur, seperti langkah keamanan dan autentikasi atau alat analitik.

Meskipun gRPC memiliki banyak keunggulan, tidak berarti tanpa tantangan. Dalam beberapa kasus—misalnya, API yang berinteraksi dengan pengguna dengan sumber data sederhana di mana kemudahan penggunaan merupakan pertimbangan utama—kerumitan yang disebabkan oleh gRPC mungkin tidak diperlukan. Tantangan gRPC meliputi:

Kompleksitas: Mendefinisikan struktur pesan dan layanan di file .proto, seperti yang dibutuhkan gRPC, bisa lebih menantang daripada bekerja dengan format berbasis teks seperti XML dan JSON.

Kemudahan penggunaan: gRPC, buffer protokol, dan HTTP/2 dapat menghadirkan kurva pembelajaran yang curam bagi pengembang yang terbiasa bekerja dengan REST.

Debug: Mungkin sulit untuk memeriksa, melakukan debug, dan mencatat aplikasi gRPC karena format biner tidak dapat dibaca oleh manusia. Ada alat yang dapat mengonversi biner, tetapi mereka memerlukan langkah tambahan, dibandingkan dengan XML atau JSON.

Kemutakhiran dan dukungan: gRPC tidak setua gaya arsitektur populer lainnya seperti REST dan tidak memiliki komunitas yang besar atau banyak plug-in dan dukungan dokumentasi. Sebagai kerangka kerja yang lebih baru, ada lebih sedikit alat (seperti alat pemindai keamanan) yang tersedia untuk gRPC dibandingkan dengan beberapa gaya yang lebih mapan.

Keterbatasan browser: Karena secara default browser web tidak mendukung protokol gRPC, layanan gRPC tidak dapat dipanggil langsung dari aplikasi berbasis browser. Salah satu cara untuk mengatasi masalah ini adalah dengan menggunakan proksi seperti gRPC-Web. GRPC-Web pada dasarnya bertindak sebagai lapisan penerjemahan antara HTTP browser dan protokol gRPC.

Aplikasi web memulai panggilan gRPC menggunakan pustaka klien JavaScript GRPC-Web untuk mengirim permintaan gRPC yang telah disesuaikan untuk kompatibilitas browser. Permintaan dikirim ke server proxy yang mengubah permintaan menjadi permintaan gRPC standar dan meneruskannya ke server backend gRPC. Server gRPC memproses permintaan, mengirimkan kembali respons ke server proxy, dan proxy sekali lagi mengubah respons ke dalam format gRPC-Web sebelum meneruskannya kembali ke klien.