README.md

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)

• [ x ] Clone https://gitlab.com/ichlaffterlalu/bambangshop-receiver to a new repository.
• STAGE 1: Implement models and repositories
  • [ x ] Commit: Create Notification model struct.
  • [ x ] Commit: Create SubscriberRequest model struct.
  • [ x ] Commit: Create Notification database and Notification repository struct skeleton.
  • [ x ] Commit: Implement add function in Notification repository.
  • [ x ] Commit: Implement list_all_as_string function in Notification repository.
  • [ x ] Write answers of your learning module's "Reflection Subscriber-1" questions in this README.
• STAGE 3: Implement services and controllers
  • [ x ] Commit: Create Notification service struct skeleton.
  • [ x ] Commit: Implement subscribe function in Notification service.
  • [ x ] Commit: Implement subscribe function in Notification controller.
  • [ x ] Commit: Implement unsubscribe function in Notification service.
  • [ x ] Commit: Implement unsubscribe function in Notification controller.
  • [ x ] Commit: Implement receive_notification function in Notification service.
  • [ x ] Commit: Implement receive function in Notification controller.
  • [ x ] Commit: Implement list_messages function in Notification service.
  • [ x ] Commit: Implement list function in Notification controller.
  • [ x ] 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 our design, we used an RwLock to protect the Vec of notifications because this lock allows multiple threads to read the data simultaneously while still ensuring exclusive access when writing. This is ideal for our scenario, where the system frequently reads notifications but only occasionally updates them. A Mutex, on the other hand, would restrict access to a single thread at any given time, even for read operations, which would unnecessarily slow down the system under heavy read loads. The RwLock thus provides a better balance between thread safety and performance in our application.

Rust enforces strict safety rules around mutable static data to prevent race conditions and data corruption. Unlike Java, where static variables can be mutated freely via static methods, Rust requires that any global mutable state be managed carefully. By using the lazy_static library, we can initialize static variables like Vec and DashMap in a controlled and thread-safe manner. This approach avoids the risks associated with direct mutation and ensures that our program remains safe even in a concurrent environment, adhering to Rust’s core design principles of memory and thread safety.

Reflection Subscriber-2

Exploring the code beyond the tutorial steps, particularly in src/lib.rs, was a valuable experience. I learned how Rust uses lazy_static to safely initialize global variables and how configuration management can be handled with crates like dotenvy and Figment. This exploration deepened my understanding of how Rust’s strict type and memory safety rules work in practice, and how these rules contribute to a more robust and reliable codebase. Additionally, I learned about custom error handling techniques, which help in creating consistent and clear error responses across the application.

Working with the Observer pattern has made it remarkably straightforward to add new subscribers. The design allows any new instance to simply register with the publisher and immediately start receiving notifications, without requiring modifications to the publisher’s logic. However, if we were to deploy multiple instances of the Main App, the ease of adding subscribers would depend on the architecture. With a centralized management system for subscribers, multiple Main App instances could share a common subscriber list, making integration seamless. If each instance managed its own list independently, additional coordination would be necessary, which could complicate the design.

I also experimented with using Postman for testing and documenting the API. This experience was highly beneficial, as it allowed me to quickly verify that endpoints worked as expected and to share well-organized test collections with my team. Features like automated tests, environment management, and detailed documentation in Postman proved invaluable for both the tutorial and future group projects. These tools not only help catch issues early but also improve collaboration and the overall quality of the software.