Author: Lee Boon Hao

Hello all, this is the last week of my internship at Tong Hin. I started this week’s internship by modifying the table sorting for payment and orders tables. Previously I had sorted the payment and sales order tables by the id. However, I have changed it to sort by the latest date, since Mr. Peter said that most of the users that use our system will prefer seeing the latest order or payment that have been made. So, I changed the “ORDER BY id” statement in these two tables to “ORDER BY datetime DESC”.

Next, I refactor the item API. I have changed the get item list query in item API to query the item list by category id instead of category name. This is because the category name may be duplicate. So, it is better to get the item list by category id. Besides that, I have also changed the get item list query by showing the uom name. Mr. Peter has told me that each item will have one uom. Furthermore, I have also changed the get item by barcode query to show the uom. Moreover, I have also changed the logic for generating random items command to generate one uom for each of the item. 

The next task that I do is to add two functions in item API. These two functions are the function that will be used in the feature of getting sales orders by id. These two private functions are not an API, so I don’t need to add it in the controller in the API project. For the first function which is the get item name and uom by single barcode query, it will return a string that will show the item and uom name by single barcode only. Firstly, I will add a filter that will return the item by the barcode. Then, I will link it to the uom collection in MongoDB in order to retrieve the uom name. Next, I will connect the item name and uom name that is being retrieved in a string and return the string. 

After that, I have done the second function which is to retrieve the item name and uom name list by barcode list query. For this function, I have used the in function for the filter so that it can filter the item based on the barcode list. Then, I will link the item to the uom collection in order to retrieve the uoms for the items. Next, I will connect the item name and uom name that is being retrieved in a string for each of the items and add it to the list of strings. Lastly, I will return the list of strings. Lastly, I have linked this function to the get order by id function in the handler part. I need to set the name and uom name for the dto in this query. Firstly, I will use the function of get item name by barcode list to retrieve the list of strings. Next, for each of the strings in the result list, I will split the string into two parts. The first part is the item name, while the second part is the uom name and set it to the dto.

After finishing these tasks, my internship has ended. During this internship, I have learned a lot about the knowledge of backend programming in order to construct an in-house system for a company. Besides that, I have also learned how to interact more with SQL databases, and MongoDB databases in order to retrieve or update data. I would like to thank you to Mr. Peter and Tong Hin company for giving me such a good opportunity to become an intern in the company. This internship has given me a good impression and it has motivated me to become a better software developer in the future.

This week, I began by reworking the item API to include the image path and uom name property to the item list dto in order to obtain the item list query. This is crucial because in order to query the item list, the frontend developer requires these properties. Additionally, when I query the item list using the search name as the basis, I also change the regex options. I’ve added the option which tells the item list query to disregard any whitespace users may have inadvertently entered.

In addition, I eliminate some superfluous DTO that is not really needed when querying item data for barcodes, as this will make the results easier for frontend developers to read. I’ve also introduced more properties, which contains the more sub-properties. In addition, I have updated the item detail dto with the UomName attribute.

Mr. Peter discovered that after looking over my code, I needed to add the uom functionality to the item API. This is so that it can remember the uom that is being made or added to each thing. I need to know the uom that is within every object. Thus, I’ve added a capability to uom that allows you to obtain uom details or lists by id. Since there would be differences in subprice for each uom, I have further included the subprice attribute for each uom.

In order to verify the requirement that the entity id and barcode cannot exist more than once, I have finally refactored the item entity API code. In order to prevent the database from returning an error each time a user adds a new item entity with the same barcode and entity ID, I inserted the unique complex key when I created the item entity table.

I carried out the remaining tasks from last week’s internship this week by putting the entity into practice. The ability to create and update commands was something I had finished. Thus, I still need to create the functionality to obtain entity by id query, get list query, and delete the entity command. Therefore, before querying the entity list and entity information by id, I started implementing the removing entity feature. When I implemented the feature of querying the entity list, I realized that I needed to add two more functions to the repository part. The first function is to get the entity list with page number and page size. Meanwhile, the second function is to get the number of entities from the query. 

Based on the search result, the handler portion of this feature will return the dto with the entity list, page size, page number, and number of entities. Mr. Peter informed me that there will only be one response to the get entity list query—an HTTP status code of 200 OK—after I had completed developing the entity entity. The response of HTTP status code 204 No Content will not be returned since it is a search function. So, I quickly fixed the problem and continue to implement another new entity.

A few fundamental CRUD operations, including the create, update, and delete entity commands as well as the get entity list and get item entity by id query, will be included in this object. 

When testing the API for this entity, I need to include the table and data from another entity, which are entity and store, in order to make the test work. The test won’t function if I don’t include the entity and store entities because the entity table is related to entity A table and the entity A table is linked to the entity B table. Mr. Peter has advised that I include a check to ensure that there are no duplicate of complex ids after I have completed creating this entity. In order to solve this puzzle, he also advised me to use complex keys. 

Since the price is required for the frontend to generate the post page, I have also included the selling price to the item API. Last but not least, Mr. Peter has requested that I include sorting to each table list. This is a result of the data’s constant inconsistency with the ids order. Consequently, I have updated each table list in the repository section with a “ORDER BY id” statement. The table will be listed in ascending order of id when the get list API is invoked.

I started this week by implementing the category API as part of my ongoing refactoring of the item API. The ability to query the category list, category by id, and other list has been implemented. In addition, I’ve introduced the ability to generate random items from the HTTP POST request using the item API. This API will generate random things with the item name “item” and a randomly generated GUID value when the user uses it. Furthermore, it will also generate more details for the item. It will also generate new brands and new categories when the user first uses the HTTP POST request. When the user uses this HTTP POST request to generate random items for the second time, it will not generate new brands and categories.

Mr. Peter suggested that I restructure the detail query once I had completed implementing the API for categories and the command for creating random items. He stated that there are several drawbacks when querying an item by its MongoDB ObjectID, which is why this query will take a long time. He advised me to use the barcode as a basis for my query to obtain the item detail since it is a unique value. In addition, he recommended that I combine the two query item lists: which is the primary query item list using the search name and the secondary query item list based on details into one. This is due to the fact that these two queries’ codes are quite similar.

I tested the item API using the Postman tool after I had made the necessary changes to it in accordance with sir’s advice. However, there is an error since I do not add the MongoDB connection variable to the docker. As a result, the server is unable to connect to the actual server. I therefore inserted the variable with the proper format, “mongodb://username:password@host:port,” to the docker file. After entering the variable for MongoDB, I rebuild the docker-compose and use the Postman to test the API again.

Adding the new entity to the retail system is my final task for this week. The name, id, code, and foreign key id will be its four properties. The link between the new entity and the store will be one to many, meaning that each store may have multiple entities. But every entity will only be associated with one store. The entity will have the feature of creating, updating, and deleting commands as well as the feature of querying list, and detail by id. Since I haven’t completed implementing this entity, I will continue to do this task next week.

I began improving the item API code this week by giving the item a new functionality that allows you to filter the item list based on a characteristic of the item. In its initial iteration, this feature consists of querying the object only by using its name. It will query the objects that, based on the filter, have the same name. I add tests to the testing class to test the API after I’ve created it. I discovered that the feature was operational. Next, I removed the unnecessary details that won’t be shown when querying the item list or querying the item list by details. This details will only be shown in the item detail page. When removing these details, I found out that I only need to remove the details shown in the dto class of the feature, since the dto class is the place that will show which details will be passed for a particular feature. 

I kept refactoring the query item list by API by adding more details to be filtered after eliminating the superfluous details that wouldn’t be displayed in the query item list feature. I have included details like model, uom, brand, and category. I discovered that certain categories might have a parent category, while other categories might not, when I added the category to the details to be filtered. As an illustration, Category B can have a parent category that is Category A. Therefore, I must include the items that belong to Category B when I want to filter the item list that contains Category A. After doing some research on the internet, I managed to find the solution that will query the item list based on the category and its child category.

After I had completed all of the item API and tests, Mr. Peter advised me to create an API that can produce random items based on the number entered by the user. As an illustration, if the user input 1000, 1000 items will be created at random. Front-end testing can be made easier using these API. In addition, he recommended that I include the categories API.

In addition, he has asked me to create a branch from the item feature branch as he has completed the sales order API. The most recent code from sir’s order feature branch will also be pulled into this branch. I will then use the Windows PowerShell to produce the codegen code. I builded up my project and updated it for server after producing the codegen code. Finally, I keep rebuilding the docker file and using Postman to test the updated API. I discovered that every API functioned well.

I’m still working on debugging the item API that needs to be connected to the MongoDB server this week. Mr. Peter discovered that my code had a number of issues. First off, I have the MongoDB server that will be used for testing incorrectly identified. I just need to connect to the local MongoDB server, construct the necessary databases, and collections within it since I need to test if the item API is functioning or not. I don’t have to establish a connection with the actual MongoDB server that houses the actual data and item metadata.

Next, Mr. Peter also realized that there is another problem in my code, which is I put the server details and login credentials when committing my work and push my work into the working branch. This is dangerous as other people may steal the server details and login credentials by looking through our codebase. So, Mr. Peter has informed me to use the git command of “git reset HEAD~1” to reset or revert back my commit and “git push origin branch -f” to delete and remove all the problems that I have made in my branch. After removing the file that includes the server details as well as the login credentials, I tried to force commit these changes and I realized that the error that I made in my working branch has been deleted.

Once the connection issues with the MongoDB server are resolved, I begin working on the item’s first feature: using pagination to query the item list based on the item name. Firstly, I tried to add an item class inside the core project that includes the details of the item, for example the id, name, others. Next, I utilized the CQRS design and put the feature of query item list by search name with pagination inside the query folder of the item. I also added mapping between the item and dto class to make sure that the data passed to the dto is correct.

In addition, I made an item controller class that will call the item’s API method inside the API project. In addition, I verified that the API test was successfully completed by testing the item controller within the API test project. Following that, I produced the query item list and details based on the item feature. Additionally, I kept adding tests for these two features, and I discovered that they also functioned properly. I’ll keep refining the item API code next week.

This week I continue to solve the API problem that I encountered last week. The issue I ran into last week was that Postman was not able to establish a connection to the database. After the guidance and advice from Mr. Peter, I can run the API on Postman correctly. The docker-compose.yml file contained some missing information, which caused the issue. Upon incorporating the data and reconstructing the docker-compose.yml, I successfully executed the API through Postman.

This week, I also ran into a problem where I couldn’t get software to connect to the database. I have attempted to establish a connection with the server and launch software again in order to access my database. The database system is in recovery mode or the database connection has timed out, according to the error message I received. Despite my attempts to use Google Chrome to remedy the issue, the error persisted. I thus told Mr. Peter about this mistake right away. He explained to me that the issue was caused by an excessive amount of memory in the log file. So, after solving the problem, I was able to run the database again.

In addition, Mr. Peter discovered that third parties had gained access to the data kept in our MongoDB. This is a result of the deletion of the database that held the item data. The MongoDB server also established a new database named “READ_ME_TO_RECOVER.” In order to prevent anyone else from accessing our MongoDB server in the future, Mr. Peter quickly shuttered it. He then built a new server and added a far more complex login and password to prevent unauthorized users from readily accessing our MongoDB.

After Mr. Peter fixed the MongoDB issue the following day, no additional new connections were made, indicating that as of right now, no hacker was attempting to steal our data. But Mr. Peter has told me to keep a close eye on the MongoDB and let him know if someone hacks our data once more. This week, I have attempted to access the MongoDB, but it continues to fail. In order for Mr. Peter to try to debug and identify the issue, he has asked me to push my workings to the feature branch.

I began this week’s work by carrying on with the customer controller tests refactoring. I have combined the address and customer table data creation into a single variable. As a result, debugging and determining whether issues occur throughout the data generating process will become simpler for other users. In addition, it will be simpler for other users to add new customers or addresses for existing customers. Finally, the code will become more comprehensible by altering the customer and address table’s data creation structure.

After modifying the data seeding on the customer controller tests, Mr. Peter has informed me to do a new task, which is to do the query for items. The items will have the query feature of get the item list by name in pagination, get the item list with the filters, and get the item details. The item query will be different from the query for the customer, since the item will be a query from MongoDB. MongoDB is a cross-platform, source-available document-oriented database system. categorized as a database software using NoSQL. Since this is new to me, I’m still learning how to query from MongoDB.

Moreover, Mr. Peter has also given me another task, which is to test my API by using the Postman app. Postman is an API platform for building and using APIs. Postman makes the entire API lifecycle easier to understand and facilitates teamwork, enabling us to produce better APIs more quickly. In order to use the API document in the frontend implementation, I must first create a subdirectory containing it. Subsequently, I must publish my API project and transfer the generated files into the user folder that I have set up in FileZilla. Subsequently, I will need to rebuild the docker file to ensure that everything goes as planned and attempt to use Postman to execute the API.

But, I encountered an issue when utilizing Postman to run the API: I am unable to connect to the database. I’ve attempted a variety of approaches to the issue, such as altering the connection string’s hostname and adding additional symbols. Still, none of the fixes I tried have been successful. So, Mr. Peter has advised me to add some log information in my project to find exactly what is the problem that led to the error of the API. I have tried to add the log information in the controller in the API project. The value of the connection string was exactly what I wanted but the problem still hasn’t been solved. I will try to solve the problem next week.

After receiving some advice from Mr. Peter last week, I’m continuing to modify the customer function this week. First off, I’ve made improvements to my test for creating and deleting commands from customers. This is accomplished by adding the addresses count. I have to make sure that the addresses that customers submit will be added to the address table when they are creating new customers. So, I must verify that the address table’s address count is accurate. I have added a new function in the repository project, which is to get the total number of addresses in the address table. Thus, I can use this function in the testing project to see if the created addresses have been added or not.

The validation for creating and updating client features has then been added by me. The customer and created addresses will be verified as legitimate by further validation. Thus, I have verified the customer’s email address and phone number. The customer must input a phone number that is between 10 and 11 characters long. In the meanwhile, the client must confirm that the email address they supplied complies with the requirements for a valid email address format. In addition, I have developed validation that will determine whether the customer supplied any duplicate addresses. Furthermore, I have also developed validation to ensure that the customer would only choose one address.

Additionally, I modified the list query’s logic such that it now just displays each customer’s default address. In the meantime, the selected customer’s details will be displayed initially by the id query. A button next to the address box allows the customer to click and view all of the addresses they have created. Following the completion of the aforementioned enhancements, Mr. Peter has requested that a swagger be created for the customer feature. With the help of a user interface (UI) called Swagger, our users will be able to test out API calls right in their browsers. It will be possible for me to construct the swagger once I have appropriately configured everything.

Finally, after successfully building the UI, Mr. Peter reviewed my code. He realized that there are some improvements in the coding part that I can refactor it. I will try to refactor the code next week.

This week I have continued to modify the customer feature. Mr. Peter had instructed me to add another table address. The customer table in the customer feature will have some relationships with the address table. Each customer will have many addresses. In addition, each customer will also have default address. Furthermore, each address can only belong to one customer. Mr. Peter continued by pointing out that I had made a mistake in the customer table, as I had accidentally used the plural word when referring to a single field.

First, I changed the column name from a plural term to a singular word in the customer table. In addition, I eliminated the extraneous column that was appended to the address table. In the customer table, I have further included the addresses. The return type of address will be present in these two attributes. In the meantime, an additional feature has been added: customer addresses. This attribute will hold a list of addresses that are specific to a given client. Next, I created the address table and included the attributes needed for the address table. I have also included the customer attribute, that has the type of customer since I need to know which address belonged to which customer. 

After creating the new address table and implementing the relationships between the customer and address table in the core project,  I will need to change each of the customer features, for example: list query, and others. The relationship I have built in the core project must be implemented in all customer features. So, I started to modify the id query. I’ll start by adding the attribute that this query will display after it is implemented. I then have to change this query’s dapper implementation. This is due to the fact that the earlier iteration of the dapper implementation only had a basic query method for retrieving data from the customer table. I must, however, query the customer and address tables for the time being. As a result, I must modify the dapper implementation such that these two tables have a one-to-many relationship. This is the trickiest part since I have to write a lot of additional code to make sure this stuff works. 

After making various changes to the dapper implementation, I can now execute the query correctly and test it multiple times. I can therefore keep changing other client features. After modifying all customer features, Mr. Peter advised me that there are several improvements that I can do for the customer features, such as adding validation when creating or updating the customer, simplifying query and others. So, I will try to improve the customer feature next week.