Month: October 2024

Monday, September 23, 2024 – Last week, I focused on refining the controller tests, particularly in contexts that typically throw errors when executed all at once, but function correctly when run individually. The root cause was the unavoidable sharing of data within a single test file that contained both query and command API tests. Following Mr. Peter’s advice, I decided to separate the tests by query and command to eliminate this issue.

I also continued enhancing the message queue I was working on. I encountered a significant problem: when the RabbitMQ server is down from the start, starting the application caused a collapse. Initially, I thought this behavior was acceptable, but Mr. Peter pointed out that since RabbitMQ is implemented on the backend, it shouldn’t impact the user interface unless an API call triggers it. Upon further investigation, I found that several frontend services also utilized the message queue service, which contributed to the issue.

To address this, I extracted the used services into a new service that integrates the message queue functionality. By the end of the week, I presented my progress to Mr. Peter, and he noted that several aspects of the message queue service still needed enhancements, which I plan to tackle next week.

Monday, September 16, 2024 – Last week, I continued my work on completing the message queue. Although I had successfully consumed and received the messages, I was initially unable to execute the intended purpose of these messages. After presenting my attempts to Mr. Peter, I learned that the issue stemmed from an unnecessary transaction I had included. It turned out that the system only required a simple update function.

Once I ensured that this part of the message queue was functioning correctly, I proceeded to implement the message queue in various components that required it. This message queue facilitates communication between microservices, ensuring that relevant data is consistently updated across the system.

Mr. Peter tasked me with cleaning up several features and services that would no longer be needed in the future. My next challenge with the RabbitMQ implementation was determining the best way to handle errors. To test this, I stopped the RabbitMQ server and attempted to start the application, which caused it to shut down immediately. To mitigate this, I added a try-catch block inside the message service constructor to ensure that errors would be thrown rather than causing the application to crash. While this approach worked, I recognized that it was not a clean or best practice solution.

Determined to refine my approach, I created specific files for managing the RabbitMQ connection, aiming to avoid hardcoding and to handle errors more effectively. However, I encountered issues during testing; it appeared that I might have missed some initializations. I plan to revisit this in the coming week.