@@ -83,6 +83,7 @@ You can install Postman via this website: https://www.postman.com/downloads/
This is the place for you to write reflections:
### Mandatory (Subscriber) Reflections
#### Reflection Subscriber-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?
RwLock<> is necessary in this case because we need to allow multiple readers to access the Vec of Notifications concurrently while ensuring that only one writer can modify it at a time. This is important for performance, as it allows multiple threads to read notifications without blocking each other. On the other hand, using Mutex<> would block all readers when a writer is modifying the data, which could lead to performance bottlenecks in scenarios with high read concurrency.
...
...
@@ -91,6 +92,15 @@ RwLock<> is necessary in this case because we need to allow multiple readers to
Rust enforces strict ownership and borrowing rules to ensure memory safety and prevent data races. Unlike Java, where static variables can be mutated directly via static functions, Rust requires explicit synchronization mechanisms like `RwLock<>` or `Mutex<>` to safely mutate shared static data. This design choice ensures that access to shared data is always thread-safe, even in concurrent environments. By using libraries like `lazy_static`, we can initialize static variables in a controlled manner while adhering to Rust's safety guarantees.
#### Reflection Subscriber-1
#### Reflection Subscriber-2
> 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.
Yes, I have explored the `src/lib.rs` file. This file contains several reusable response type, application confuguration, and error handling. I learned that the `lib.rs` file serves as the entry point for the application, and it is where we can define reusable components and configurations that can be shared across different modules. This helps in maintaining a clean and organized code structure, making it easier to manage dependencies and configurations for the entire application.
> 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?
The Observer pattern simplifies the process of adding more subscribers by allowing them to register themselves with the publisher (Main app) without requiring any changes to the publisher's code. Each subscriber can independently subscribe or unsubscribe from notifications, making it easy to add or remove subscribers as needed. This modularity allows for greater flexibility and scalability in the system.
> 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).
Yes, I have tried to enhance the documentation on my Postman collection by adding detailed descriptions for each endpoint, including request and response examples. This has been very useful for my work as it provides clear guidance on how to use the API and helps in understanding the expected behavior of each endpoint. Additionally, creating tests in Postman has allowed me to automate the verification of API responses, ensuring that the system behaves as expected and reducing the chances of introducing bugs during development.
