Monday, July 14, 2025 – Last week, I was assigned to build a new API query for an existing UI. Previously, the UI directly accessed the repository without going through an API layer. To improve separation of concerns and promote loose coupling, I was tasked to create an API query so that the UI now communicates with a proper API endpoint instead of directly interacting with the repository. This helps enforce dependency inversion, where the higher-level UI module no longer depends on lower-level data modules directly, but instead communicates through defined interfaces (API).
In addition to creating the new query, I was also tasked with implementing caching for this API but without using Redis. Instead, I would need to use in-memory caching. Before tackling the cache, I focused on completing the query.
One key difference with this new query is that it pulls two separate item lists from two different databases, yet still returns them in a single response. Despite the difference, the implementation remained relatively straightforward.
Once the query was complete, I wrote a simple test and moved on to the next task: implementing the UI. I followed the previous design pattern with one main difference. Previously, the system used two separate views merged into one page. However, since the new query provides both lists in one call, only one view and one view model were needed. This change helped simplify the UI structure.
By the end of the week, I had completed the UI. However, more testing and refinement are still needed, especially since this UI will be reused in multiple features. I also need to finalize the caching mechanism, which I plan to continue next week.