gRPC Tutorial

Nama: Joshua Montolalu
NPM: 2306275746
Kelas: Pengjut A

Modul 8

Reflection

1. What are the key differences between unary, server streaming, and bi-directional streaming RPC (Remote Procedure Call) methods, and in what scenarios would each be most suitable?
   

   • Unary adalah bentuk komunikasi di mana sebuah client mengirim satu request kepada server, kemudian server mengembalikan satu response kepada client. Ini mirip dengan bentuk komunikasi yang digunakan dalam REST API dan cocok digunakan untuk aplikasi web yang sederhana.

   • Server streaming adalah bentuk komunikasi di mana client mengirim satu request kepada server, kemudian server mengembalikan sebuah stream yang berisi data response yang berurutan. Server streaming cocok digunakan jika response yang ingin dikirim dari server berukuran besar sehingga harus dipisah-pisah.

   • Bi-directional streaming adalah bentuk komunikasi di mana client dapat mengirim sebuah stream data kepada server, dan server juga dapat mengirim sebuah stream data kepada client. Bi-directional streaming cocok digunakan untuk komunikasi real-time antara server dan client yang melibatkan banyak data, seperti chat service.

2. What are the potential security considerations involved in implementing a gRPC service in Rust, particularly regarding authentication, authorization, and data encryption?
   

   • Beberapa pertimbangan keamanan dalam implementasi gRPC dalam Rust adalah sistem autentikasi and otorisasi untuk memastikan bahwa client yang mengirim request benar-benar merupakan pihak yang berhak untuk melakukan operasi yang sensitif, seperti mengakses atau mengubah data pribadi. Untuk itu, gRPC menyediakan objek Credentials agar kita dapat melakuakan autentikasi antara client dan server. Selain itu, Credentials dapat digunakan untuk mengenkripsi data saat transit antara client dan service lewat protokol SSL/TLS. Hal ini penting agar pihak luar tidak dapat mencegat komunikasi antara client dan server dan data yang terkirim tetap rahasia.

3. What are the potential challenges or issues that may arise when handling bidirectional streaming in Rust gRPC, especially in scenarios like chat applications?
   

   • Beberapa tantangan yang mungkin terjadi saat menggunakan bidirectional streaming dalam Rust gRPC adalah konkurensi pada banyak stream (pesan yang concurrent dapat menimbulkan masalah race condition), menjaga alur pengiriman dan penerimaan data agar terjaga keutuhan dan konsistensi data, masalah backpressure ketika ada banyak pesan dari client, dan mengatur koneksi antara client dan server (jika client timeout atau disconnect).

4. What are the advantages and disadvantages of using the tokio_stream::wrappers::ReceiverStream for streaming responses in Rust gRPC services?
   

   • Karena tokio_stream::wrappers::ReceiverStream terintegrasi baik dengan tokio dan Tonic, kita dapat melakukan streaming gRPC seperti kita melakukan streaming biasa dengan menggunakan wrapper di atas tokio::sync::mpsc::Receiver. Kekurangan dari penggunaan tokio_stream::wrappers::ReceiverStream adalah perlu konfigurasi manual jika kita perlu menangani kasus-kasus seperti pembatasan pesan (menggunakan kapasitas channel) atau kasus lain. Ini dapat membuat kode kita lebih kompleks dan panjang untuk handling operasi asinkronus yang aman.

5. In what ways could the Rust gRPC code be structured to facilitate code reuse and modularity, promoting maintainability and extensibility over time?
   

   • Kode gRPC yang sudah dibuat dapat distruktur untuk menjaga prinsip clean code dan meningkatkan maintainability dengan melakukan pemisahan logika seperti pada API standar. Misalnya, melakukan pemisahan menjadi service layer (bagian yang menangani business logic) dan server layer (bagian yang menangani server gRPC). Kemudian, service layer dapat dipisah lagi menjadi repository layer untuk memisahkan business logic dan logic untuk berinteraksi dengan data store (seperti database) agar kode kita lebih modular. Selain itu, testing merupakan faktor yang penting untuk mendukung maintainability, sehingga perlu ditambahkan berbagai jenis testing untuk memastikan kode kita sudah berjalan dengan baik.

6. In the MyPaymentService implementation, what additional steps might be necessary to handle more complex payment processing logic?
   

   • Untuk menerapkan sistem pembayaran yang lebih kompleks, ada baiknya jika kita menerapkan sistem keamanan seperti autentikasi dan autorisasi untuk menjaga keamanan data kita. Selain itu, enkripsi data juga dapat dilakukan untuk memastikan data sensitif seperti nomor kartu kredit atau informasi pembayaran lainnya dijaga rahasia. Perlu juga diimplentasi validasi/sanitasi input, sistem error handling yang baik, dan penyimpanan data yang aman dan efisien di dalam sebuah database. Sistem logging juga dapat ditambahkan agar admin sistem dapat memantau transaksi pembayaran yang masuk.

7. What impact does the adoption of gRPC as a communication protocol have on the overall architecture and design of distributed systems, particularly in terms of interoperability with other technologies and platforms?
   

   • Penggunaan gRPC sebagai protokol komunikasi membuat komunikasi antar sistem dan layanan lebih mudah karena lebih terstruktur dengan adanya schema untuk mendefinisikan kontrak penggunaan. Selain itu, karena gRPC sudah mendukung banyak bahasa pemrograman, komunikasi antar layanan dapat dilakukan dengan lebih efisien karena client dapat memanggil fungsi pada server seolah-olah fungsi tersebut ada di client, bahkan antara bahasa pemrograman yang berbeda. gRPC juga sudah menggunakan protokol HTTP/2 dan Protocol Buffer sehingga komunikasi antar layanan dapat berjalan dengan lebih cepat dan efisien dengan multiplexing dan compression.

8. What are the advantages and disadvantages of using HTTP/2, the underlying protocol for gRPC, compared to HTTP/1.1 or HTTP/1.1 with WebSocket for REST APIs?
   

   • Keuntungan menggunakan HTTP/2 dibandingkan dengan HTTP/1.1 (+ WebSocket) adalah adanya fitur multiplexing (pipelining) yang memungkinkan pengiriman banyak request dalam satu koneksi, fitur header compression yang mampu mengecilkan ukuran setiap request dan response, dan fitur server push di mana server dapat mengirim data ke client sebelum adanya request eksplisit dari client. Namun, kekurangan dari HTTP/2 dibandingkan dengan HTTP/1.1 adalah tingkat support dan compatibility yang lebih kecil dan sistem yang lebih kompleks untuk dibaca dan di-debug oleh manusia.

9. How does the request-response model of REST APIs contrast with the bidirectional streaming capabilities of gRPC in terms of real-time communication and responsiveness?
   

   • Pada REST API, request-response model membatasi interaksi antara client dan server kepada koneksi yang hanya terdiri atas satu request dan satu response dari server. Ini membuat komunikasi real-time kurang efektif karena adanya overhead untuk membuka dan menutup koneksi setiap kali ingin mengirim atau menerima data. gRPC menyediakan solusi untuk masalah ini dengan bidirectional streaming di mana pada satu koneksi, client dan server dapat saling mengirim dan menerima pesan sehingga komunikasi real-time dapat berjalan dengan lebih responsif dan lebih cepat tanpa perlu membuka banyak koneksi.

10. What are the implications of the schema-based approach of gRPC, using Protocol Buffers, compared to the more flexible, schema-less nature of JSON in REST API payloads?
    

    • Karena gRPC berjalan pada schema yang sudah terdefinisi sebelumnya, kita dapat menjaga konsistensi data yang dikirim dan diterima antar server dan client. Ini membuat aplikasi kita lebih rigid karena kita sudah tahu sebelumnya bentuk data yang perlu kita kirim dan bentuk data yang akan kita terima. Sebaliknya, REST API tidak memiliki batasan schema seperti ini sehingga tidak ada guarantee atau jaminan terhadap data yang kita terima dari client. Ini membuat REST API lebih fleksibel karena tidak ada batasan terhadap data yang dikirim, namun kekurangannya adalah kita harus melakukan validasi sendiri terhadap data yang diterima dan memastikan bahwa sudah sesuai dengan apa yang kita harapkan. Satu implikasi lain dari penggunaan format JSON vs Protocol Buffer adalah JSON ditulis dalam plain text sehingga dapat dibaca oleh manusia dan lebih mudah di-debug. Di sisi lain, Protocol Buffer akan mengubah data yang dikirim ke dalam bentuk biner untuk menghemat data yang perlu dikirim oleh server dan client. Tradeoff dari ini adalah payload yang dikirim dan diterima akan lebih susah dibaca dan di-debug oleh manusia.