Month: June 2025

Tuesday, June 3, 2025 –  Last week, I was assigned a new backend-related task. The objective was to enhance an existing API by adding a few new properties to one of the current entities.

I started by updating the existing database diagram using Visio to reflect the new properties. Since the system uses MongoDB, there was no need to handle database migrations, MongoDB’s schema-less nature made the update process more straightforward.

After confirming the updated design with Mr. Peter, I proceeded to add the new properties directly into the existing entity class. These properties didn’t require any new relationships, so I was able to jump straight into modifying the update command. Note that the create command didn’t need any changes, as the new fields weren’t involved in initial data creation.

Once the update command logic was in place, I wrote a new unit test to ensure the changes worked as expected. After verifying that the backend logic was functional, I moved on to the UI. The UI changes were relatively simple, involving just an additional checkbox. I created the wrapper component and mapped the new property accordingly.

However, during testing, the update functionality didn’t behave as expected. Although everything seemed correctly configured, the data wasn’t updating. This led me to re-run the unit tests. One of them failed, while another passed but revealed that a property expected to be non-nullable was receiving zero or empty data instead.

After some debugging and with help from Mr. Peter, we discovered the issue: a DTO (Data Transfer Object) required the same property name as the corresponding entity to ensure correct mapping. Once this was corrected, everything functioned as expected. With the update logic complete, I’ll now move on to the Get List API Query, which I plan to work on next week.

Monday, May 26, 2025 – Continuing from last week’s progress, I was assigned a new task: to hide the actual backend API URL from the client. Previously, the client exposed the API URL whenever a user made a request. Although our backend was already secured with proper authentication and authorization mechanisms, we wanted to add an additional layer of protection to prevent outsiders from even knowing the real API URL.

Initially, my first approach was to call the API from the server side, aiming to mask the actual URL. However, I quickly ran into a challenge, this approach would require rewriting each API call manually. Considering that there are potentially hundreds of endpoints, this method was not practical or scalable.

Eventually, I came across a more efficient solution: implementing a reverse proxy using Nginx. The idea behind a reverse proxy is that all client requests are routed through the Next.js server, which in turn forwards them to the backend API. This setup effectively hides the real backend URL, as the client only sees the requests going to the Next.js frontend. In addition, it allows for better control over request handling, logging, and access restrictions.

However, during a code review session with Mr. Peter, we discovered a flaw in my implementation. While the reverse proxy did manage to change the port and redirect the requests, it didn’t completely fulfill the goal. The real backend endpoint was still accessible, meaning it wasn’t truly hidden from external users. Our actual objective was to ensure that the backend communicates only with the Next.js frontend, preventing any direct access from outsiders. Unfortunately, my current setup didn’t enforce that restriction.