1. Perbedaan Metode RPC dan Pengguananya :

• Unary = Client mengirim satu request dan Server mengembalikan satu respons. Unary RPC ideal untuk operasi yang sebatas pengambilan atau pengubahan satu entitas—misalnya proses autentikasi, pengambilan data profil pengguna, atau eksekusi perintah sederhana pada API tradisional karena sifatnnya request-respond tunggal. Dengan unary, tidak ada overhead open‑stream lama. Setelah response diterima, koneksi gRPC ditutup kembali.

• Server Streaming = Client mengirim satu request dan server mengembalikan banyak respons. Implementasi cocok jika server harus kirim banyak data secara bertahap / sequencial. Misalnya feed notifikasi real‑time, live score pertandingan, atau sinkronisasi data batch. Klien dapat mulai memproses data begitu potongan pertama tiba, tanpa menunggu keseluruhan payload, sehingga mengurangi latensi untuk data “streaming” besar.

• Bi-Driectional Streaming = Client dan Server dapat mengirim pesan independen secara bersamaan di dalam satu koneksi yang sama tanpa harus menunggu giliran masing-masing (mengirim banyak pesan satu sama lain di continous stream). Implementasi cocok untuk komunikasi 2 arah (app chat, game multiplayer,real time collab app).

2. Pertimbangan Keamanan gRPC Rust :

• Autentikasi dapat dilakukan dengan mengintegrasikan JWT (JSON Web Token) atau protokol OAuth. JWT memungkinkan server untuk memverifikasi identitas pengguna dengan memvalidasi signature token dan membaca informasi identitas yang terkandung dalam payload. Proses ini biasanya diimplementasikan dengan memanfaatkan metadata pada request dan menggunakan library seperti jsonwebtoken di Rust. Untuk menjaga pemisahan logika bisnis dan keamanan, autentikasi sebaiknya diletakkan dalam interceptor — sebuah middleware yang dijalankan sebelum handler utama gRPC.
• Otorisasi dengan pendekatan umum yang digunakan adalah Role-Based Access Control (RBAC), di mana setiap pengguna memiliki peran tertentu seperti admin, user, atau viewer. Peran ini biasanya disisipkan dalam JWT dan diperiksa pada saat request dijalankan. Selain RBAC, dapat juga diterapkan validasi izin kontekstual, yaitu pemeriksaan izin yang bergantung pada situasi tertentu
• Data Encryption pada seluruh komunikasi antara klien dan server harus dienkripsi menggunakan TLS (Transport Layer Security). Di Rust, khususnya dengan framework seperti tonic, pengaturan TLS dapat dilakukan dengan konfigurasi sertifikat X.509 untuk memastikan enkripsi di lapisan transport. Namun, dalam beberapa kasus seperti pengolahan data yang sangat sensitif, enkripsi tambahan pada tingkat payload (end-to-end encryption) juga diperlukan. Ini bisa dilakukan dengan mengenkripsi konten data secara manual menggunakan algoritma seperti AES sebelum dikirim melalui gRPC, dan hanya didekripsi di sisi penerima.

3. Tantangan dalam Bi-directional Streaming :

• Pengelolaan resource dan memory leak apabila terjadi putus koneksi secara tiba-tiba dari sisi klien. Saat klien terputus secara mendadak—baik karena gangguan jaringan maupun crash aplikasi—stream. di server, harus segera dibersihkan debngan buffer internal dibuang, handle I/O ditutup, dan task asynchronous yang menunggu I/O dihentikan. Di Rust, hal ini dapat diakomodasi dengan menerapkan trait Drop pada objek stream, serta memanfaatkan tokio::sync::watch
• Koordinasi concurency / multi thread dalam message sending. concurrency coordination muncul karena pesan dapat dikirim dan diterima secara simultan oleh banyak thread atau task. Runtime async seperti Tokio memungkinkan spawn banyak future, namun kita harus memastikan bahwa akses ke stream tidak menimbulkan deadlock atau data race.
• Manajemen State: Menghindari race condition saat akses data bersama. Dalam skenario streaming dua arah, sering kali terdapat shared state, misalnya cache hasil partial computation atau counter urutan pesan. Jika dua buah task asynchronous memodifikasi state ini tanpa sinkronisasi, hasilnya bisa tidak deterministik atau bahkan korup. Untuk itu, setiap akses state kritikal harus dibungkus dalam guard—tokio::sync::Mutex untuk eksklusif write atau tokio::sync::RwLock
• Implementasi batas waktu dan mekanisme heartbeat untuk mendeteksi putusnya koneksi. Implementasi batas waktu (timeout) dan mekanisme heartbeat mutlak diperlukan untuk mendeteksi koneksi “mati” sekaligus mencegah resource terjebak dalam keadaan menunggu tanpa akhir. gRPC menyediakan opsi deadline per RPC; di Rust/tonic, ini diatur melalui Request::set_timeout atau konfigurasi Interceptor yang menambahkan metadata deadline.

4. tokio_stream::wrappers::ReceiverStream:

• Kelebihan : tokio_stream::wrappers::ReceiverStream menyederhanakan pemrosesan pesan asynchronous dengan langsung mengubah mpsc::Receiver menjadi sebuah Stream yang bisa dipakai bersama sintaks async/await. Karena dibangun di atas channel Tokio, ia otomatis menahan (backpressure) apabila konsumen lebih lambat daripada produsen, sehingga mencegah penumpukan buffer dan potensi kebocoran memori. Abstraksi ini juga menghilangkan kebutuhan menulis state‑machine atau menangani waker secara manual, sehingga kode menjadi lebih ringkas dan mudah dipelihara.

• Kekurangan : Di sisi lain, ReceiverStream hanya membungkus satu channel sehingga kurang fleksibel bila Anda perlu menggabungkan beberapa sumber data atau melakukan kontrol aliran secara rinci. Apabila terjadi kesalahan atau panic pada sisi pengirim, konsumen hanya akan melihat stream terhenti tanpa informasi penyebab, sehingga penanganan error harus ditambahkan secara eksplisit. Selain itu, sebagai lapisan abstraksi, ada overhead kecil dalam alokasi dan polling dibanding solusi custom yang langsung memanfaatkan primitive asynchronous tingkat rendah.

5. Struktur kode agar modular dan resuable dapat dilakukan dengan :

• Melakukan pemisahan proto, implementasi layanan, dan kode client ke halaman terpisah seperti yang dilakukan di source code tugas kali ini untuk grpc_client.rs dan grpc_servic.rs dan services.proto di directory tersendiri. Dengan demikian, skema pesan dan API tetap terisolasi dari logika bisnis dan detail transport, memudahkan tim frontend maupun backend untuk berkolaborasi tanpa saling menginjak kode satu sama lain.
• Penggunaan traits untuk abstraksi implementasi layanan dari logika bisnis. Trait ini hanya mendeklarasikan method­-method bisnis tanpa mengikat pada detail penyimpanan atau transport. Implementasi konkret trait kemudian diinjeksi ke dalam server gRPC saat inisialisasi.
• Injeksi depedensi untuk repository data, konfigurasi, dan komponen lain sangat membantu menjaga loose coupling antar komponen. Contohnya untuk repository (manajemen fungsi logika dengan database), konfigurasi TLS, client external juga dapat diinjeksi ke dalam struct implementor trait menggunakan constructor.
• Penerapan middleware sebagai lapisan terpisah untuk fungsionalitas lintas potongan seperti auth atau logging sebelum dan sesudah pemanggilan handler.
• Dapat dilakukan implementasi modul / fitur seperti payment,chat,auth yang masing‑masing berisi proto, implementasi trait, konfigurasi DI, dan repository terkait. Dengan struktur seperti ini, setiap modul dapat dikembangkan, diuji, maupun di‐deploy secara independen.

6. Implementasi MyPaymentService :

• Pemisahan lapisan arsitektur menjadi controller/Service Layer (gRPC handler) hanya bertugas menerima request, memanggil service bisnis, dan mengubah hasilnya ke Response, lalu business Logic sebagai layer implementasi trait terpisah (misal PaymentProcessor) yang mengurusi aturan bisnis, fee calculation, risk check, dan sebagainya. Terakhir adalah repository Layer sebagai interface (trait) untuk akses data (misal PaymentRepository) dengan implementasi konkret menggunakan Diesel/SQLx.
• Idempotency & Replay Protection yang dilakukan ntuk menghindari duplikasi (misal klien retry karena timeout), mintalah client mengirimkan idempotency key di header metadata. Simpan key ini di database dan jika request dengan key sama datang lagi, langsung kembalikan hasil sebelumnya tanpa memproses ulang.
• Melakukan validasi dan error handling seperti pre-condition jumlah saldo dan metode transaksi, dan detail sumber dana.
• Melakukan logging dan tracing dalam proses pembayaran untuk tracking lifecycle request yang dikirmkan user / customer.
• Implementasi timeout sebagai batas waktu transaksi pada RPC (Request::set_timeout(...)) dan di service layer gunakan tokio::time::timeout untuk membatasi durasi tiap langkah. Jika layanan eksternal, bungkus dengan retry policy (exponential backoff) agar tahan transient failure.
• Validasi keamanan menggunakan autentikasi / otorisasi dengan Json Web Token (JWT) di interceptor.
• Lakukan unit testing sebagai tahapan akhir untuk validasi fungsionalitas di berbagai case (happy & unhappy path).

7. Dampak adopsi gRPC sebagai ptotokol komunikasi terhadap keseluruhan arsitektur software dan desain dari sistem terdistribusi, terutama dalam konteks interoperability dengan teknologi lain dan platform lain :

• Standarisasi Kontrak Layanan. Meskipun dilakukan dengan bahasa pemrograman berbeda, kontrak data akan sama persis seperti yang di encode / decode dengan implementasi Protocol Buffers oleh gRPC sebagai interface definition language (IDL) di satu file .proto untuk skema message dan API nya.
• gRPC yang dibangun di atas HTTP/2 dengan fitur multipliexing, header compression, dan presistence connection, dapat berdampak pada penurunan latensi pada saat pengiriman data dengan format biner Protocol Buffer yang lebih padat dibanding JSON. Hal tersebut mampu mempercepat gRPC 7 sampai 10 x dibanding REST over HTTP/1.1.
• gRPC mempermudah integrasi komponen di platform berbeda karena dapat digunakan di berbagai bahasa pemrograman (C#,C++,C,RUST,dll.) sehingga dapat dipanggil oleh microservice lainnya tanpa adapter khusus (tinggal menggunakan stub/ stub-generated client).
• gRPC-Web menggunakan proxy yang dapat menerjemahkan HTTP/1.1 di browser dan HTTP/2 di server sehingga menambah lapisan infrastruktur, gateaway atau sidecar untuk menghubungkan aplikasi web dan tetap menjaga interoperabilitas.

8. Perbandingan HTTP/2 sebagai protocol underlying /gRPC dibanding HTTP/1.1 atau HTTP/1.1 untuk WebSocket

• Keuntungan : Multiplexing dapat dilakukan HTTP/2 dengan banyak stream (request/response) paralel di satu koneksi TCP. Sedangkan HTTP1/1.1 harus menunggu satu response. Binary Framing HTTP/2 dapat mengemas semua messages dan parsingnya lebih cepat dan hemat bandwith, sedangkan HTTP/1.1 lebih banyak over-head parsing dan trasnfer. Header Compressionnya efektif mengurangi overhead metadata per request sedangkan header HTTP/1.1 selalu berupa teks. Cookies dan header nya yang panjang juga menambah beban setiap request. Untuk infrastruktunya pun cukup HTTP/2-capable server / proxy, sedangkan HTTP/1.1 dengan WebSocket perlu melakukan handshake upgrade dan servernya harus mendukung websocket juga.

• Kelemahan : Set up TLS/HTTP2 kadang lebih rumit dan juga HTTP/2 streaming bisa dilakukan dengan sayrat browser yang memerlukan gRPC-Web, bukan full-duplex native di JavaScript. Sedangkan HTTP/1.1 dengan WebSocket sudah di handle dengan menyediakan persistence connection full-duplex out of the boc yang ideal untuk chat/game. Koneksi HTTP/2 juga bersifat long-lived, sehingga kegagalan koneksi mampu berdampak lebih luas dibandingkan HTTP/1.1 yang bersifat short-lived. Implementasi HTTP/2 juga lebih kompleks dibandingkan HTTP/1.1 karen protokol binary format tidak terlalu readable tanpa tools khusus walaupun lebih efisien. Ini akan menyulitkan dalam proses maintainance maupun troubleshooting. HTTP/1 yang menggunakan enkripsi TLS juga dapat menambah kompleksitas konfigurasi walau menjaga keamanan lebih.

9. REST API yang bermodel Unary Streaming(Request/Response) dan gRPC yang bermodel Bidirectional Streaming.

Kontras yang jelas antar REST dan gRPC dari segi real-time communication dan resposivitas dapat dijabarkan dari aspek inisiasi komunikasi, keterhubungan, overhead, latensi, model komuniaksi, backpressure handling, dan parsing payload.

Dengan REST, klien selalu memulai request terlebih dahulu dan server me-respons sekali setiap request, sedangkan gRPC membuka koneksi / channel sekali, lalu klien dan server bisa saling kirim pesan kapan saja lewat stream yang sama. REST juga umumnya memiliki koneksi ke HTTP/1.1 walaupun HTTP/2 keep-alive ada dengan sifat indpenden di setiap requestnya. Sedangkan gRPC persisten HTTP/2 untuk aliran message bolak balik tanpa harus buka tutup kokenksi berulang. REST juga menyertakan HTTP header lengkap dan overhead TCP handshake jika ada koneksi baru dan overhead makin besar apabila dilakukan polling real-time. Hal tersebut juga memicu latensi yang tinggi karena pasa saat polling real-time dibutuhkan update selagi klien mengirimkan request berkala. Sedangkan pada gRPC, Header hanya di-negosiasi sekali dan pesan selanjutnya dikirim sebagai frame Protocol Buffer kecil yang memungkinkan overhead tiap pesan relatif lebih rendah. Latensinya pun turut rendah karen server bisa langsung melakukan "push" data ke klien segera setelah tersedia tanpa menunggu request baru terlebih dahulu. Model komunikasi untuk REST berupa suatu siklus satu arah dengan klien -> server -> klien, sedangkan untuk gRPC lebih bersifat bidirectional klient <-> server secara independen.

REST tidak memiliki penanganan backpressure bawaan sehingga klien diminta untuk dapat mengatur po;;ing interval sendiri, sedangkan gRPC dengan underlying protocol HTTP/2 menyediakan flow control & back-pressure yang dapat mencegah buffer ovverrun. Untuk parsing payload, REST menggunakan JSON teks pada umumnya yang di mana data lebih besar dan parsing menjadi lebih lambat dibandingkan gRPC dengan protocol buffer binary frame yang dapat meningkatkan thorughput dan mengurangi latesi CPU.

10. Implikasi Skema berbasis gRPC dan payload JSON di REST API :

• gRPC mewajibkan definisi message dan layanan di file .proto dengan kompilasinya yang menghasilkan stub/klien/server dengan tipe data yang sudah dijamin sejak compile sehingga kesalahan dapat terdeteksi sebelum runtime sehingga bisa mencegah injection akibat payload tak terduga juga. Sedangkan payload JSON tidak diwajibkan mengikuti skema tertentu dengan validasi tipe data di runtime sehingga memungkinkan terjadinya undetected error. Diperlukan library / JSON Schema Validator terpisah untuk memastikan struktur dan tipe data.
• Binary Serialization dengan PRotocol Buffer gRPC pun lebih ringkas dan cepat dibandingkan JSON teks milik REST API sehingga bandwith lebih rendah dan CPU Parisng lebih hemat.
• gRPC juga mendungkun addition / redirect ulang field dengan aturan numbered-field. Namun perlu dilakukan definisi formal terlebih dahulu seperti di dalam file .proto, tidak seperti REST yang fleksibel untuk menambah / membuang field, namun berdampa pada kesulitan dalam kompatibilitas dan butuh dokumentasi eksternal seperti OpenAPI / JSON Schema.
• gRPC pun otomatis generate kode untuk banyak bahasa dengan IDE pun bisa auto complete sehingga bisa refactoring secara aman. Tidak seperti REST API yang perlu setting manual atau bisa otomatis dengan dokumentasi OpenAPI yang tetap memerlukan validasi untuk mencegah error di runtime.
• Namun gRPC kurang fleksibel dibanding REST karena dibitihkan perubahan skema tersendiri untuk gRPC di .proto / regenerate stub. Sedangkan REST sangat fleksibel karena klien/ layanan dapat ebrtukar data ad-hoc tanpa harus melakukan modifikasi pada codebase.