@@ -77,7 +77,40 @@ This is the place for you to write reflections:
### Mandatory (Publisher) Reflections
#### Reflection Publisher-1
>1. In the Observer pattern diagram explained by the Head First Design Pattern book, Subscriber is defined as an interface. Explain based on your understanding of Observer design patterns, do we still need an interface (or trait in Rust) in this BambangShop case, or a single Model struct is enough?
<palign="justify">In this case, using an interface is unnecessary because there's only a single, consistent Subscriber type. All of the subscribers behave the same way and the logic is simple enough that one struct suffices. This keeps the code clean and straightforward.</p>
>2. id in Program and url in Subscriber is intended to be unique. Explain based on your understanding, is using Vec (list) sufficient or using DashMap (map/dictionary) like we currently use is necessary for this case?
<palign="justify"> Using a DashMap is necessary here because it enables efficient access to Subscribers via their unique URLs. This is particularly important for sending notifications, as we need to target specific subscribers. In contrast, using a Vec would require scanning the entire list to locate the right subscriber, which is slower and less efficient.</p>
>3. When programming using Rust, we are enforced by rigorous compiler constraints to make a thread-safe program. In the case of the List of Subscribers (SUBSCRIBERS) static variable, we used the DashMap external library for thread safe HashMap. Explain based on your understanding of design patterns, do we still need DashMap or we can implement Singleton pattern instead?
<palign="justify">DashMap is preferred over implementing a traditional Singleton pattern because Rust’s ownership model makes Singleton implementations more complex. DashMap already provides built-in thread safety and efficient concurrent access, which are crucial for web applications. By relying on a well-tested library like DashMap, we reduce the risk of subtle concurrency bugs. Additionally, Rust encourages the use of its type system and ownership model over classic OOP patterns whenever possible.</p>
#### Reflection Publisher-2
>1. In the Model-View Controller (MVC) compound pattern, there is no “Service” and “Repository”. Model in MVC covers both data storage and business logic. Explain based on your understanding of design principles, why we need to separate “Service” and “Repository” from a Model?
<palign="justify">Separating Model, Service, and Repository helps create a more structured and maintainable codebase. It clearly divides data access (Repository) from business logic (Service), allowing each part to be developed and tested independently. This approach also supports reusability and scalability, following the Single Responsibility Principle, since changes in one component won’t impact the others.</p>
>2. What happens if we only use the Model? Explain your imagination on how the interactions between each model (Program, Subscriber, Notification) affect the code complexity for each model?
<palign="justify">Without separating the Service and Repository layers, the Model ends up handling all the core application logic, resulting in a tightly coupled, monolithic structure. This makes the code harder to maintain, test, and scale as new features are added. It also increases complexity, raising the risk of bugs and making the overall application flow more difficult to follow due to the lack of clear boundaries between responsibilities.</p>
>3. Have you explored more about Postman? Tell us how this tool helps you to test your current work. You might want to also list which features in Postman you are interested in or feel like it is helpful to help your Group Project or any of your future software engineering projects.
<palign="justify">Yes, I have explored Postman. This software helps me test the API that I have created by simulating a request and getting the response. I think the features that will be beneficial for my group projects are the team collaboration and the automated testing.</p>
#### Reflection Publisher-3
>1. Observer Pattern has two variations: Push model (publisher pushes data to subscribers) and Pull model (subscribers pull data from publisher). In this tutorial case, which variation of Observer Pattern that we use?
<palign="justify">In this tutorial, the Push Model is used, as the publisher actively sends notifications to subscribers whenever a product is created or deleted. Subscribers don’t have to request updates—they receive them automatically as the publisher pushes the data.</p>
>2. What are the advantages and disadvantages of using the other variation of Observer Pattern for this tutorial case? (example: if you answer Q1 with Push, then imagine if we used Pull)
<palign="justify">The Pull model offers both benefits and drawbacks. A key advantage is that subscribers can decide when to fetch updates, which can be useful in some situations. However, this adds complexity since subscribers must handle the logic for retrieving data themselves. It can also cause delays in receiving updates, as subscribers might not check for new information regularly.</p>
>3. Explain what will happen to the program if we decide to not use multi-threading in the notification process.
<palign="justify">If we choose not to use multi-threading for the notification process, the application will handle notifications sequentially, causing the main thread to block while waiting for each HTTP request to complete. Slow or unresponsive subscribers can delay the entire process, leading to timeouts and reduced responsiveness. As the number of subscribers grows, notification time increases linearly, harming scalability. There's also a higher risk of deadlocks if a subscriber interacts with the publisher during the wait, and failed notifications could delay or prevent delivery to others.</p>
