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.