/bambangshop-receiver

AdvProg Module 7 Receiver App

Primary LanguageRust

BambangShop Receiver App

Tutorial and Example for Advanced Programming 2024 - Faculty of Computer Science, Universitas Indonesia


About this Project

In this repository, we have provided you a REST (REpresentational State Transfer) API project using Rocket web framework.

This project consists of four modules:

  1. controller: this module contains handler functions used to receive request and send responses. In Model-View-Controller (MVC) pattern, this is the Controller part.
  2. model: this module contains structs that serve as data containers. In MVC pattern, this is the Model part.
  3. service: this module contains structs with business logic methods. In MVC pattern, this is also the Model part.
  4. repository: this module contains structs that serve as databases. You can use methods of the struct to get list of objects, or operating an object (create, read, update, delete).

This repository provides a Rocket web framework skeleton that you can work with.

As this is an Observer Design Pattern tutorial repository, you need to implement a feature: Notification. This feature will receive notifications of creation, promotion, and deletion of a product, when this receiver instance is subscribed to a certain product type. The notification will be sent using HTTP POST request, so you need to make the receiver endpoint in this project.

API Documentations

You can download the Postman Collection JSON here: https://ristek.link/AdvProgWeek7Postman

After you download the Postman Collection, you can try the endpoints inside "BambangShop Receiver" folder.

Postman is an installable client that you can use to test web endpoints using HTTP request. You can also make automated functional testing scripts for REST API projects using this client. You can install Postman via this website: https://www.postman.com/downloads/

How to Run in Development Environment

  1. Set up environment variables first by creating .env file. Here is the example of .env file:

    ROCKET_PORT=8001
    APP_INSTANCE_ROOT_URL=http://localhost:${ROCKET_PORT}
    APP_PUBLISHER_ROOT_URL=http://localhost:8000
    APP_INSTANCE_NAME=Safira Sudrajat

    Here are the details of each environment variable:

    variable type description
    ROCKET_PORT string Port number that will be listened by this receiver instance.
    APP_INSTANCE_ROOT_URL string URL address where this receiver instance can be accessed.
    APP_PUUBLISHER_ROOT_URL string URL address where the publisher instance can be accessed.
    APP_INSTANCE_NAME string Name of this receiver instance, will be shown on notifications.
  2. Use cargo run to run this app. (You might want to use cargo check if you only need to verify your work without running the app.)

  3. To simulate multiple instances of BambangShop Receiver (as the tutorial mandates you to do so), you can open new terminal, then edit ROCKET_PORT in .env file, then execute another cargo run.

    For example, if you want to run 3 (three) instances of BambangShop Receiver at port 8001, 8002, and 8003, you can do these steps:

    • Edit ROCKET_PORT in .env to 8001, then execute cargo run.
    • Open new terminal, edit ROCKET_PORT in .env to 8002, then execute cargo run.
    • Open another new terminal, edit ROCKET_PORT in .env to 8003, then execute cargo run.

Mandatory Checklists (Subscriber)

  • Clone https://gitlab.com/ichlaffterlalu/bambangshop-receiver to a new repository.
  • STAGE 1: Implement models and repositories
    • Commit: Create Notification model struct.
    • Commit: Create SubscriberRequest model struct.
    • Commit: Create Notification database and Notification repository struct skeleton.
    • Commit: Implement add function in Notification repository.
    • Commit: Implement list_all_as_string function in Notification repository.
    • Write answers of your learning module's "Reflection Subscriber-1" questions in this README.
  • STAGE 2: Implement services and controllers
    • Commit: Create Notification service struct skeleton.
    • Commit: Implement subscribe function in Notification service.
    • Commit: Implement subscribe function in Notification controller.
    • Commit: Implement unsubscribe function in Notification service.
    • Commit: Implement unsubscribe function in Notification controller.
    • Commit: Implement receive_notification function in Notification service.
    • Commit: Implement receive function in Notification controller.
    • Commit: Implement list_messages function in Notification service.
    • Commit: Implement list function in Notification controller.
    • Write answers of your learning module's "Reflection Subscriber-2" questions in this README.

Your Reflections

This is the place for you to write reflections:

Mandatory (Subscriber) Reflections

Reflection Subscriber-1

In this tutorial, we used RwLock<> to synchronise the use of Vec of Notifications. Explain why it is necessary for this case, and explain why we do not use Mutex<> instead?

  1. Di tutorial ini kita menggunakan RwLock<> dibanding Mutex<> untuk mengsinkronisasi vektor Notification karena RwLock<> memungkinkan beberapa thread untuk membaca vektor Notification tersebut, sedangkan jika kita menggunakan Mutex<>, hanya 1 thread saja yang dapat membaca vektor Notification dalam suatu waktu. Jika hanya ada 1 thread yang dapat membaca vektor tersebut dalam suatu waktu, tentu itu akan menjadi bottleneck pada aplikasi kita karena bisa saja ada beberapa bagian dari aplikasi kita yang membutuhkan untuk membaca vektor Notification tersebut namun terblokir karena ada thread lain yang sedang membaca datanya. Dengan menggunakan RwLock<>, kita dapat menjamin thread-thread dapat membaca vektor Notification kapan saja dan tidak terblokir namun hanya boleh 1 thread yang menulis ke vektor tersebut dalam suatu waktu.

In this tutorial, we used lazy_static external library to define Vec and DashMap as a “static” variable. Compared to Java where we can mutate the content of a static variable via a static function, why did not Rust allow us to do so?

  1. Rust tidak membiarkan kita memutasi variabel static karena dalam lingkungan multi-threaded, jika terdapat variabel static yang dapat diakses secara global, susah untuk menjamin bahwa tidak akan terjadi race condition pada data tersebut. Oleh karena itu, library lazy_static digunakan untuk menjamin bahwa variabel static kita aman untuk digunakan secara multi-threaded.

Reflection Subscriber-2

Have you explored things outside of the steps in the tutorial, for example: src/lib.rs? If not, explain why you did not do so. If yes, explain things that you have learned from those other parts of code.

  1. Saya sempat melihat-lihat file lain yang ada pada aplikasi publisher dan receiver ini. Dari apa yang saya pahami, file src/lib.rs pada kedua aplikasi akan me-load file .env (jika ada) dan mengubah setting default yang sebelumnya di deklarasi di file tersebut menjadi setting yang ada di file .env. File src/lib.rs juga mendeklarasikan tipe Result<T, E> yang merupakan tipe dari std::result::Result<T, E> namun dengan modifikasi bahwa E disini adalah sebuah tipe error custom Custom<Json<ErrorResponse>>. Terdapat pula sebuah fungsi compose_error_message yang berguna untuk membuat sebuah error dengan tipe Custom<Json<ErrorResponse>>. Secara keseluruhan, file src/lib.rs mengandung tipe-tipe dan variable-variable pembantu yang nantinya akan digunakan oleh aplikasi kita.

Since you have completed the tutorial by now and have tried to test your notification system by spawning multiple instances of Receiver, explain how Observer pattern eases you to plug in more subscribers. How about spawning more than one instance of Main app, will it still be easy enough to add to the system?

  1. Dengan pattern Observer, saya dapat dengan mudah menambahkan instance Subscriber baru karena saya hanya perlu mengkonfigurasi port berbeda. Saya tidak harus melakukan konfigurasi-konfigurasi aneh lainnya dan setelah port sudah dikonfigurasi, Subscriber bisa langsung subscribe ke suatu product_type tanpa harus mengkonfigurasi hal-hal lain di aplikasi Publisher. Jika saya ingin menambahkan instance dari Main app, saya harus menambahkan domain dari instance baru tersebut ke konfigurasi di Receiver app. Namun, Subscriber nantinya juga harus melakukan subscribe dahulu ke domain dari Main app yang baru ditambahkan sebelum bisa menerima notifikasi karena tiap Main app tidak membagikan data pada versi ini. Receiver app harus diubah sedikit implementasi subscribe dan unsubscribe nya agar ketika fungsi tersebut dipanggil, fungsi tersebut akan mengirimkan request ke semua domain Main app, bukan hanya satu.

Have you tried to make your own Tests, or enhance documentation on your Postman collection? If you have tried those features, tell us whether it is useful for your work (it can be your tutorial work or your Group Project).

  1. Saya belum pernah mencoba membuat Test saya sendiri pada Postman, namun dari Test yang diberikan di koleksi, sepertinya Test di Postman layaknya Test biasa. Menurut saya, fitur tersebut dapat membantu tugas kelompok saya karena saya dapat dengan mudah membuat Test untuk semua API endpoint yang ada di tugas kelompok saya tanpa harus membuatnya dalam bentuk code.