Fakultas Ilmu Komputer UI

Skip to content
Snippets Groups Projects
Commit e0e60a5a authored by TheoKevH's avatar TheoKevH
Browse files

finish reflection

parent 12b81587
No related branches found
No related tags found
No related merge requests found
......@@ -85,5 +85,24 @@ This is the place for you to write reflections:
### Mandatory (Subscriber) Reflections
#### Reflection Subscriber-1
>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?
<p align="justify">Using RwLock<> is important here because it enables multiple threads to read the notifications concurrently, while still ensuring exclusive access when a write occurs. This improves performance by allowing non-blocking reads, which is beneficial in situations with frequent read operations. In contrast, using a Mutex<> would block all readers during a write, potentially creating performance issues under high read concurrency.</p>
>2. 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?
<p align="justify">In Rust, static variables are handled differently from Java due to Rust's strict ownership and memory safety rules. While Java allows static variables to be modified freely, Rust requires explicit synchronization mechanisms like RwLock or Mutex to safely mutate static data across threads. Tools like lazy_static combined with locking ensure that static variables can be initialized at runtime and accessed safely in multithreaded contexts. Without these, Rust prevents mutable access to static data to avoid race conditions, reflecting its philosophy of “fearless concurrency” enforced at compile time.</p>
#### Reflection Subscriber-2
>1. 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.
<p align="justify">Yes, I explored beyond the tutorial steps, particularly in <code>src/lib.rs</code>, which serves as the application's entry point and shows how the Rocket framework is configured. Through this exploration, I learned how Rocket’s fairing system adds extra functionality to the server, how environment variables are loaded and used throughout the app, and how the application architecture is structured with clear separation between controllers, services, and repositories.</p>
>2. 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?
<p align="justify">The Observer pattern makes it much easier to add new subscribers, as each receiver instance can independently subscribe to specific product types without the publisher needing to know about them in advance. Adding a new receiver is as simple as launching a new instance with its own port and name. This separation between subject and observer is a key strength of the pattern. However, scaling the publisher is more complex. Running multiple publisher instances requires a shared product database, a way to synchronize subscriptions across instances, and load balancing for incoming requests. The Observer pattern alone doesn’t address these challenges, as it’s mainly designed for one-to-many notifications.</p>
>3. 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).
<p align="justify">Yes, I’ve improved the documentation in my Postman collection by including detailed descriptions for each endpoint along with request and response examples. This has been helpful in providing clear instructions on how to use the API and understanding the expected behavior of each endpoint. Additionally, writing tests in Postman has helped automate API response validation, ensuring the system works as intended and minimizing the risk of bugs during development.</p>
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment