Transitioning from Dummy APIs to Custom API Integration in Next.js

Monday, December 9, 2024 – Over the past week, I transitioned from using an online dummy JSON API to integrating a custom API into the website under development. Initially, the dummy API was instrumental in building the website’s basic layout. Once that phase was complete and a custom API was developed, I began implementing API calls into the project. However, before proceeding with the integration, I needed to synchronize data into the MongoDB database. After completing the sync, I referred to the guide shared by Mr. Peter for further implementation.

Previously, while using the dummy JSON API, I utilized a fetch function that allowed me to retrieve data without relying on useEffect, enabling the page to remain server-rendered. Unfortunately, this approach did not work with the custom API integration. After multiple attempts to implement server-side rendering for the custom API, the approach still failed. Consequently, I decided to switch to using useEffect for client-side rendering as a temporary solution, with plans to revisit and resolve the issue in the future.

Working with the API in Next.js required me some adjustment, particularly in understanding the exceptions being thrown and the proper way to handle them. The custom API created by Mr. Peter also includes admin functionalities such as updating records. By the end of the week, I was able to replace all the previous dummy API calls such as retrieving lists, fetching data by code, and updating entries with our own API.

MongoDB and Brand API

Ninth week as an intern in Tong Hin. A new task has come by on Monday. Starting the week with learning MongoDb, spend half a day to look on videos and documents. After getting a grasp of it, I need to think and consider the design for the brand. There are some requirements of the brand such as redirecting of brand URL if brand name has changed and to generate the xml.

Continuing with the test and controller on Tuesday, it was partially done and I received a task on convert and read WebP. Spend an hour to try it out and it all works. At the end of Tuesday, Mr. Peter mentioned about storage and want me to check and compare between Amazon S3 and other ways.

Moving on to Thursday, solved some questions of Tuesday, Trying out magick.Net and it can generate GIF based on input image regardless of file types. After that, look into how to set image order and I suggested make a imageDTO. Beside that, I did also do some research on the storage about cloud or local server but it wasn’t done and not fully understanding what the concept is before Mr. Peter explained one more time.

Following that, resuming on research and trying out. I have listed out the cloud server and local server storage to be consider. Looking through article and Stackoverflow, I have get a better knowing and a voice from all the other user who are using it. I tried it out with the local file explorer first and it work but there is a security concern about file explorer. I will try out the others on next Monday.

Summary

In summary, this week focus on a new task. The task is to do brand API and leading to cloud and local server. Researching let me learn more as this is a new area for me. I appreciate the experience provided here at the workplace.

Week 8 Internship: Fixing Whole System Bugs and Create Voucher Page

Fixing Whole System Bugs

Since Mr. Peter has reviewed my entire system, he pointed out some small bugs that could be enhanced to make it smoother. There were over 20 tasks, and it took me two days to complete. These tasks included fixing some input bugs, such as ensuring the page auto-focuses when navigating or when selecting items, as well as allowing decimal inputs for stock management.

In addition, I improved the workflow for stock adjustments. Now, when a user enters a wrong barcode, the system resets all states and refocuses the textbox. I also added a confirmation dialog to the payment edit section to ensure users do not accidentally click the button. Furthermore, I implemented some hotkeys: the Escape key now closes open dialogs, and the Enter key skips the need to press the submit button.

Create Voucher Page

After fixing all the bugs, the system now runs more smoothly than before. I then continued working on the voucher page. The voucher page is easier to create because it only requires three data fields to be uploaded to the API. However, one important thing to watch out for is ensuring that the “last valid date” is not earlier than the creation date. If it is, the API will return an error. To prevent this, I added validation to the “last valid date” to ensure the voucher can be created successfully.

Research On How to Create 1,000,000 Records

After finished the voucher page, the whole system are almost done , but since others backend technologies are still haven’t done yet, so that Mr.Peter asked me to do some research on generating 1,000,000 records data and see how the system performance going on if data fully loaded. It modifies that if this system are being used for several years and look whether the system still can run smoothly. After two days of researching , I have founded a platform name cypress, it is a web testing tools, but it’s more on UI testing. After trying to create a test plan , it can create records smoothly. Unfortunately, Mr.Peter does not accept this type of solution, because it would not work when the UI position are being changed. After that I was trying to create another UI page to generate the data, how I do is just hardcode the data structure and run it in a loop according to the count what user want. But this would make several hours to generate 1,000,000 records.

Complete address and user API for Web Project

Eighth week as an intern in Tong Hin. I have finally done all the assigned task. Continuing with last Friday problems, user test do not pass with the authorize in controller. I have solved the problem with removing the authorize, that does solved the problem but do not validate the token.

After some day, Mr. Peter look into my code and saw the client problem. The whole time I was doing with 2 different secret for the token which made the authorize problem. After renaming the secret, all the problem were solved. The code and logic works as the problem are with the secret key. I was also asked to do test script to test regarding the user authorization. It was an hour job.

Moving on, I started to committing the work I have done. Time move to Thursday, Mr. Peter asked me to do client credentials. It was something I am unfamiliar with it, took some time to learn and trying on. I did try and make but It wasn’t what it should be. Mr. Peter figured it is hard for me and will just let it be. I do enjoy the process of trying and learning. The week end with cleaning code and will assigned me a new task on next Monday.

In summary, I have finally completed the task and moving on to a new task. Looking back at my work, I think time does fly. It happened in a blink of eye as I enjoy my work. I am also looking forward for next week new task.

Internship (Week 8): Transfer development and refinement

Based on discussions with Mr. Peter, I focus on the Transfer API call functionality, which only interacts with Mongo on each create and update. I initially create the necessary files such as commands, as well as controllers, repositories, interfaces, tests, collections and services. After implementing these components, I directly create the sample data containing the required order details. I then update the controller to read the data to test whether the call function was successful. As I successfully retrieve the data, I continue the create command and keep improving the service. I also manually test this feature by calling the POST API to create a new order, and it worked just fine for the first try. This makes me feel very accomplish and I will continue to update the instructions tomorrow. Soon, Mr. Peter mention that any nullable data should not be seen in the Mongo express interface.

Moreover, I try to update controller tests to initialise data and set up the test environment correctly. After that, I continue on the create and update commands, constantly refining the logic and handling exceptions. At the same time, I also push my user and retail contexts for review. When Mr. Peter reviewed it, he pointed out a major problem with the controller design. The controller should only contain a Mediator constructor. I took his feedback seriously, I then add relevant queries in a timely manner and push an updated version. Mr. Peter also find that there were some unnecessary changes in my work, and require me to review and try to delete irrelevant code.

Other than that, I continue on refining the commands and services. The update command is particularly frustrating due to the complexity of handling multiple states. I found myself struggling to find the best process, I keep questioning myself and iterating on my logic. Meanwhile, I also push my works to Mr. Peter, he still flagged some unnecessary elements in the code base that made it cluttered and confusing. This was a difficult realisation because I had to face the fact that I was adding complexity instead of clarity. Mr. Peter suggested using SourceTree to compare commits line by line.

Additionally, since the deadline was getting closer, I spend the day reverting unnecessary changes as quickly as possible. During our discussion with Mr. Peter, we discovered a serious misunderstanding that I keep synchronising data incorrectly by creating or updating a local dataset instead of just focusing on MongoDB. I then modifying and refining the sync commands to be consistent with the correct context and ensure the API and tests were running as expected. When I successfully manual test the updated sync commands, I felt a sense of relief and renewed confidence. Later, I start to adjust the testing in retail and user contexts. However, there was an error on the user side that I couldn’t resolve in the end and will continue tomorrow.

Beyond that, after a lot of hard work, I finally find the solution and pass the test. I then review my work again until satisfy, then I commit and push to the repository. I then turn my attention back to completing the command and service. Soon, I found out the create command shouldn’t have any big issues. Later that day, Mr. Peter and I discussed about the item adjustments during the ordering process along with some additional requirements to be updated.

Conclusion

Looking back on this week, I experience all sorts of frustrations. I begin to realise the importance of clarity, communication and iteration in coding and collaboration. I keep refining and modifying the commands and the services in order to achieve better logic. While there is still much room for improvement, I will keep my encouragement to handle the challenges ahead.

Creating Dynamic Data Grouping

Monday, December 2, 2024 – Continuing the development process, I implemented the core functionality for displaying the data groups in a newly created component. The primary goal was to create an interactive and user-friendly interface where users could navigate the brands grouped by their initial characters.

To achieve this, I introduced a filtering mechanism using buttons for each group, such as “A-Z,” “0-9,” and special characters. The state management was handled using the useState hook to track the currently selected group. This allowed me to dynamically update the displayed data based on user interaction.

One of the significant challenges was ensuring a seamless experience while maintaining clean and reusable code. Each button was styled conditionally based on its state, whether it’s active, disabled, or default to provide visual feedback to the user so that the user won’t be able to click the group with the empty list. The “All” button was also included for users to reset the filter and view all available groups.

To display the grouped data, I designed a layout where each group had a header styled distinctly to highlight the group name. The list of brands under each group was displayed as cards, each containing an image and a title. I used Next.js’s Image component for optimized image loading and included links to next pages for further exploration.

Next, I focused on cleaning up the entire codebase before pushing the changes. Previously, the API URLs were hard coded directly into each page, which is a poor practice as it risks exposing sensitive information. To address this, I centralized the API URL by placing it in an environment file, enhancing security and maintainability. Additionally, I thoroughly reviewed the codebase to ensure no unnecessary or redundant code remained.

Week 7: Create Return Order Page

Fix Line Item Problem

This Monday, I found an issue with the line item functionality while creating an order. Regardless of the item I ordered, it always showed item 1’s line item. After debugging, I discovered that the item ID was hardcoded to 1 while uploading the line items. I resolved this issue and implemented a new function to handle the selected line item and upload it to the API.

Return Order page

Next, I continued work on the return order page. Most of my time was spent on the “Edit Return Order Details” view. I was figuring out how to display the line items correctly, as the detail view included both selected and non-selected line items. I tried to combine these two elements, showing selected items with a ticked checkbox and non-selected items with an unticked checkbox. However, my attempts faced issues, such as duplicate entries or incorrectly unticked selected items. This problem took me 1-2 days to resolve. Eventually, I found a solution by printing all the line items from the invoice, comparing them with the return order DTO, and ticking the items that matched. This method helped me better understand how to handle line item data while updating an existing return order.

At the same time, I faced another challenge regarding the return order line item ID and the invoice line item ID. Initially, I didn’t understand the difference and used the return order line item ID as both IDs while updating the return order. This caused issues where incorrect items were displayed after uploading or the upload failed entirely. After completing the line item display functionality, I finally understood how the IDs work. Differentiating between the two IDs was difficult because the line item ID to upload depends on various scenarios. Users might select new line items, modify existing ones, or perform both actions simultaneously. Implementing this logic took me 2-3 days, but I eventually succeeded in fully updating all the required data.

After completing the main part of the return order, I enhanced the search bar in the list view. I noticed the “Get Query” function allowed three types of search data, so I added a dropdown menu to let users select their search type, such as by name, and IDs.

Conclusion

In conclusion . this week, I resolved significant issues with line item handling, improved my understanding of line item ID logic, and enhanced the return order page and search functionality.

Internship (Week 7): User manager implementation with exception handling

This week, according to Mr. Peter’s suggestion and I start by adding a new user manager file that overrides specific methods within the identity server. By utilising the base function which includes the overridden virtual method of user create, update and delete operations. As each method are able to execute in both SQL and MongoDB. After successfully implementing these operations, I proceed with manual testing. During this process, I encounter service issues and quickly realise that forget to include the necessary services. Once the services are added to both the API and the identity server, I login and test all CRUD operations again. While this time, everything function perfectly, it is a relief to see my hard work pay off with smooth operations across the board.

Soon, I continue by manually testing the synchronization process between systems to ensure everything work flawlessly. Luckily, I encounter no issues during this phase, giving me confidence to proceed with mock testing for the user manager component. Meanwhile, during his review, Mr. Peter noticed a lack of exception handling in the user manager. He advised prioritising MongoDB operations before SQL. He also suggested adding more exception handling when in the event of an error, operations will roll back to their previous state.

Moreover, I apply similar enhancements to the context by adding more exceptions to both sync commands and the service. After the testing and necessary updates, I extend these improvements to the context. Next, I update the controller tests with the similar base tests of factory and initialising data. While the controller tests run smoothly, I encounter a issue with missing services during user manager mock testing. I seek advice from my colleague but couldn’t resolve it so I consult Mr. Peter. He then clarified that I need to use the new user manager file instead of the original one. However, further issues persisted, he suggested we might need to set up a separate project for testing but continue on manual testing.

Besides that, I review my works push to my feature branch for Mr. Peter’s review. He then pointed out some minor improvements, such as removing unnecessary API calls and addressing test failures. I review and refine my work and discover that I hadn’t commit the latest user service updates. Meanwhile, I remain determined to resolve the user manager testing issues. I notice that both the identity server and API referenced the Data folder, so I move the user manager file there and add the specific service. To my surprise, this approach works and the tests ran successfully. Meanwhile, Mr. Peter suggested to integrate the store Mongo repository into the user context to associate each registration with the appropriate ID.

Additionally, I include the mongo repository along and refine the context to ensure operations only read from the store collection when necessary. Afterward, I update the user manager and run the operations workflow one last time to confirm that everything worked flawlessly. When everything works as expected, I update and run the tests before pushing my final changes. Apart from that, as my user manual synchronising done, Mr. Peter then discussed with me on the next task of transfer order. He then suggested me on watching some Mongo videos.

Conslusion

This week, I have resolve service integration issues and improve user manager through improved exception handling. The challenges through rigorous testing has enhanced system reliability and my problem-solving abilities.

Lot of changes on original for improvement

Seventh week as an intern in Tong Hin. Resuming last week task, done the Read and Update for address including the test. All the test have gone through and pass.

Second, had added the 3 address id on user to check on each address purpose. The address and user is now same as the Entity Relationship Diagram.

Third, the test has some problem when run all. Some test had been using the same set of data to proceed and end up failing. I had done separate data and test with it. The test can be run all at once and pass now.

Fourth, due to misunderstanding, I have done the check token by sending it with the body request. It was suppose to be at the header and check for the token claims. I have changed it to header and it works except for the test. The test can’t locate where’s the token at.

Last but not least, Mr. Peter look through my code and found out there some problems. The password is visible at the backend which might lead to exposure. Besides that, I have used httpContextAccessor. This might be a extra thing to move on.

In summary, I had done different changes to improve the logic and making it complete. This week has been a busy week for me. Will continue the problems that haven’t solve on next week. Hope that can solve it quickly.