README.md

BambangShop Publisher 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 and methods to access the 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 basic functionality that makes BambangShop work: ability to create, read, and delete Products. This repository already contains a functioning Product model, repository, service, and controllers that you can try right away.

As this is an Observer Design Pattern tutorial repository, you need to implement another feature: Notification. This feature will notify creation, promotion, and deletion of a product, to external subscribers that are interested of a certain product type. The subscribers are another Rocket instances, so the notification will be sent using HTTP POST request to each subscriber's receive notification address.

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 Publisher" folder. This Postman collection also contains endpoints that you need to implement later on (the Notification feature).

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:

   APP_INSTANCE_ROOT_URL="http://localhost:8000"

   Here are the details of each environment variable:

   variable	type	description
   APP_INSTANCE_ROOT_URL	string	URL address where this publisher instance can be accessed.

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.)

Mandatory Checklists (Publisher)

• Clone https://gitlab.com/ichlaffterlalu/bambangshop to a new repository.
• STAGE 1: Implement models and repositories
  • Commit: Create Subscriber model struct.
  • Commit: Create Notification model struct.
  • Commit: Create Subscriber database and Subscriber repository struct skeleton.
  • Commit: Implement add function in Subscriber repository.
  • Commit: Implement list_all function in Subscriber repository.
  • Commit: Implement delete function in Subscriber repository.
  • Write answers of your learning module's "Reflection Publisher-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.
  • Write answers of your learning module's "Reflection Publisher-2" questions in this README.
• STAGE 3: Implement notification mechanism
  • Commit: Implement update method in Subscriber model to send notification HTTP requests.
  • Commit: Implement notify function in Notification service to notify each Subscriber.
  • Commit: Implement publish function in Program service and Program controller.
  • Commit: Edit Product service methods to call notify after create/delete.
  • Write answers of your learning module's "Reflection Publisher-3" questions in this README.

Your Reflections

This is the place for you to write reflections:

Mandatory (Publisher) Reflections

Reflection Publisher-1

In the traditional Observer pattern, a Subscriber is defined as an interface (or trait in Rust) to ensure that any type acting as a subscriber implements a common set of methods. In our BambangShop case, even though we currently have only one type of subscriber represented by a single Model struct, I believe it is beneficial to use a trait. Adopting a trait now provides flexibility for future expansion; if different subscriber behaviors become necessary later on, the trait ensures that they all adhere to the same contract without requiring a complete redesign of the system.

When considering the uniqueness of elements like the id in Program or the url in Subscriber, choosing the right data structure is critical. A simple Vec might work when the number of items is very small and operations are infrequent. However, since these identifiers need to be unique and quickly accessible, using a DashMap (which functions like a thread-safe HashMap) is more appropriate. This data structure offers faster lookups, insertions, and deletions, especially under concurrent conditions, ensuring that our system remains efficient as it scales.

Rust’s strict safety guarantees push us to consider thread-safe data handling at every turn. In our implementation, we opted for DashMap to maintain a global list of subscribers because it inherently manages synchronization across threads. While one could consider implementing a Singleton pattern with a plain HashMap to provide a single shared instance, that approach would force us to add our own synchronization layers (using Mutex or RwLock), complicating the design. DashMap simplifies this by offering built-in, concurrent-safe operations, making it a more straightforward solution in a multithreaded environment.

Reflection Publisher-2

In an MVC compound pattern, the Model often takes on both data storage and business logic roles, but separating out the Service and Repository components is essential from a design principles standpoint. This separation follows the Single Responsibility Principle, which states that each component should only have one reason to change. By isolating the business logic in a Service and the data access in a Repository, we ensure that each part of the system remains focused, easier to test, and more adaptable to future changes. This clear division not only simplifies maintenance but also makes the code more modular, allowing us to improve or replace one part without affecting the others.

If we were to use only the Model for handling both business logic and data persistence, the interactions between different entities—like Program, Subscriber, and Notification—would become tangled. Each model would need to manage its own data operations and logic, leading to duplicated code and tightly coupled components. This would quickly escalate the code complexity, making it hard to track how changes in one model affect the others. In such a scenario, any update in business logic might inadvertently impact data access routines, increasing the risk of bugs and making the system more difficult to maintain or scale.

I have also explored Postman as a tool to test my current work, and I found it incredibly useful. Postman allows me to quickly send API requests and verify responses, which is essential for ensuring that endpoints function correctly. I appreciate features such as automated testing scripts, environment management for easily switching between development and production settings, and the ability to organize requests into collections. These features not only streamline the testing process for my individual projects but also provide valuable documentation that can be shared with my group members, improving collaboration and overall project quality.

Reflection Publisher-3

For our notification system, we implemented the Observer pattern using the push model. In this approach, the publisher immediately sends notifications to subscribers as soon as an event occurs, ensuring that all subscribers are updated in real time. This method simplifies the process because the publisher takes full responsibility for initiating communication, reducing the need for subscribers to repeatedly check for updates.

If we were to use the pull model instead, subscribers would have to request updates at regular intervals or on demand. While this gives subscribers more control over when they receive data, it introduces potential delays and increases the overhead on both the publisher and subscribers. Frequent polling could lead to unnecessary load and slower reaction times when immediate notification is essential. In our case, the push model aligns better with the need for timely notifications and simpler logic overall.

Not employing multithreading for the notification process would mean that all notifications are handled sequentially on a single thread. This could cause significant delays, especially when there are many subscribers or when processing each notification takes time. The application would become less responsive, as lengthy notification handling could block other operations. By leveraging multithreading, we can process notifications concurrently, ensuring that the main application remains responsive and that each subscriber receives updates without undue delay.