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

1. Is an interface (or trait) needed in BambangShop, or a single Model struct is enough?

   In the Observer design pattern, an interface (trait) is typically used to define a contract for the Subscriber to ensure that all subscribers implement the required methods, such as update. However, in this case, we only have one type of Subscriber and no plans to extend it with different behaviors, so a single Model struct might suffice. Using a trait would be more beneficial if we anticipate having multiple types of subscribers with varying implementations of the update method.

2. Is using Vec (list) sufficient or is DashMap (map/dictionary) necessary for unique id in Program and url in Subscriber?

   Using a Vec would require additional step to ensure uniqueness, such as iterating through the list to check for duplicates before adding a new item, which can be inefficient as the list grows. On the other hand, DashMap inherently enforces uniqueness of keys and provides efficient lookups, making it a better choice for managing unique id and url values. Moreover, DashMap is thread-safe, which is crucial in a concurrent environment.

3. Do we still need DashMap or can we implement Singleton pattern instead for the List of Subscribers (SUBSCRIBERS)?

   The Singleton pattern ensures a single instance of a resource, but it does not inherently provide thread safety. On the other had, DashMap is specifically designed for thread-safe concurrent access to a map-like structure. Using DashMap simplifies the implementation of thread-safe data structure and reduces the risk of concurrency issues. Therefore, DashMap is a more practical choice for this case.

Reflection Publisher-2

1. Why do we need to separate “Service” and “Repository” from a Model in the MVC compound pattern?

   Separating "Service" and "Repository" from the Model adheres to the Single Responsibility Principle (SRP). The Model focuses on representing the data structure, while the Repository handles data storage and retrieval, and the Service encapsulates business logic. This separation improves code maintainability, testability, and scalability by ensuring each layer has a distinct responsibility. It also allows for easier modifications, without affecting other parts of the application.

2. What happens if we only use the Model?

   If we only use the Model, the interactions between Program, Subscriber, and Notification would become tightly coupled, leading to increased code complexity. Each Model would need to handle its own data storage, retrieval, and business logic, resulting in bunch of duplicated codes and higher risk of bugs. For example, the Notification model might need to directly query Subscriber data and manage its own notification logic, making it harder to isolate and test individual components. The lack of separation would make the codebase less flexible and harder to maintain as the application grows, which makes it unscalable.

3. How does Postman help in testing my current work?

   Postman allows me to send HTTP requests to me endpoints and verify their responses. For the current project, Postman helps in testing the Notification and Product endpoints by simulating real-world API interactions. Additionally, Postman's automated testing scripts can validate response data, ensuring that the API behaves as expected.

Reflection Publisher-3

1. Which variation of Observer Pattern do we use in this tutorial?

   In this tutorial case, we use the Push model of the Observer Pattern. The publisher (BambangShop) actively sends notifications to the subscribers whenever an event occurs, such as the creation, deletion, or promotion of a product.

2. What are the advantages and disadvantages of pull model of Observer Pattern for this tutorial?

   If we were to use the Pull model instead, advantages include:

   • Subscribers have more control over when and how they retrieve data, reducing unnecessary notifications.
   • It can be more efficient if subscribers only need updates occasionally or under specific conditions.

   However, the disadvantages include:

   • Increased complexity for subscribers, as they need to implement logic to periodically check for updates.
   • Potential delays in receiving updates, as subscribers might not pull data immediately after an event occurs.
   • Higher risk of missing critical updates if the subscriber fails to pull data in time.

3. What will happen to the program if we decide to not use multi-threading in the notification process?

   If we do not use multi-threading, then the program will handle notifications sequentially. which means:

   • The main thread will be blocked while sending notifications, potentially causing long delays in other requests.
   • The overall performance of the application will degrade significantly, especially if there are many subscribers or if the notification process involves network latency.
   • Application could become unresponsive during the notification process.