Getting to use ASP.NET Core Identity

Fourth week as an intern in Tong Hin. Last Friday, Mr.Peter mention about Identity on ASP.NET Core for the testing. I do some research on it on Monday and found out that Core Identity (calling this for short term) is to create user but with more promising security. Core Identity is a membership system provided by Microsoft that handles authentication, authorization, and user management features. This give us more time to focus on the business logic than the security. It took me some time to learn and to implement it.

Due to the Web application that might grow bigger and bigger, I think it is good to implement Core Identity as it provide password hashing and able to support multiple authentication schemes, such as cookie-based, JWT, and third-party OAuth providers.

On Monday, Mr.Peter asked me to do some research on Core Identity and state the advantages between our custom user and Core Identity’s users. After that, done some experiment on the sandbox repository with Core Identity and it was all good. After sorting out some questions related to Core Identity, Mr.Peter asked me to do user creation by using AspNetUsers provided by Core Identity and using the API approach which the project have been using. Beside that, I also need to create a function that can get the token when the user logins using the API approach.

Nevertheless, token is consider a new thing for me as I have no idea how implementing that thing and how it worked in the system. After some time of research and understanding the flow, I understand that the system’s token generator is only for testing after Mr.Peter telling. This lead me to replicate and modify a similar token generator in another file to do the job.

All job was done on Friday as I done the job with fulfilling the minimum requirement to ensure that all function and testing can be achievable. After that, Mr.Peter ask me to add other column that the real system going to implement and it is the end of the week.

In summary, a new thing to learn on the start of the week. It is a week that I learnt about something new for me and might get challenging as I dig through. It is still a fun and exciting week for me as I get to know things I am new to.

Week 4 Internship : Fix Bugs and Create Stock Adjustment Page

This week, I worked on resolving bugs related to multiple alerts occurring at the same time and stacking together. I found a new component to replace the original SweetAlert2 which is the 1st generation of it , and after replacing it, the new component successfully handled errors when multiple alerts occurred simultaneously. I also solved the issue where users could still perform actions on a page after manually deleting cookies without refreshing the page. I added an interval to monitor the cookie status every 0.1 seconds. This way, if a user manually deletes cookies or if they expire, the cookie check function can detect it as quickly as possible, force the user to navigate to the login page, and prompt them to log in again.

On another day, Mr. Peter asked me to create a stock adjustment feature that would allow users to adjust the stock they want. The first UI design I presented was rejected, so I created a new UI that focused more on usability. The most complicated part was calling multiple APIs to collect data, which I then had to combine into a command that would call another API to upload the stock data. It was quite challenging for me, but after 2-3 days of effort, I successfully solved the logic and it now runs smoothly, uploading data without issues.

After that, Mr. Peter asked me to write unit tests for the stock adjustment page. If I’m still not familiar with it, I can try to enhance the order page instead. I found that the order page had many bugs, such as the last person calling the update function after clicking the create button, and issues with the delivery method that prevented orders from being created. So, next week, I will focus on fixing these issues to improve the smoothness of the POS system during order creation.

Internship (Week 3): Project Integration and Synchronisation Progress

This week I continued my work using another project context folder to continue my user projects. Mr. Peter provided me with the retail project folder which was considered to be the main project I was going to work on. I tried to add a new migration and update the database to the PostgreSQL database, and I successfully ran the swagger API. I also cloned the repository and started a new feature branch by initialising git flow. Also, when I tried to execute the user project, I noticed that the user database connection was not found or not connected. So, I asked Mr. Peter and he replied me that the project should be connected to MySQL. Then, I can also access the POS system, work with my colleagues and explore front-end and back-end applications.

In addition, I also focus on running and understanding the existing functions of the system while troubleshooting through various experiments. I use a scanner device to explore frontend and backend applications. These practical experiences helped me become more familiar with them. I continued to investigate potential errors in the system and consulted with Mr. Peter to clarify some issues. At the same time, I also wrote some API code and tried to get the data and update it into the database, but I failed.

Moreover, Mr. Peter also gave me some tasks about user dataset synchronization, such as manual and automatic synchronization. I first successfully set up a database in MySQL Workbench. However, I got some errors on the server connection, I discussed the issue with my colleague and she thought it was an issue with missing MySQL docker containers and tried adding some but still couldn’t connect. We tried to resolve the issue with YouTube by reinstalling and reconfiguring the server, but still failed, so we asked Mr. Peter about the error. Soon, he discovered the docker issue and provided me with a Docker YAML file to start. I then successfully established the MySQL database connection and was able to connect to the created database and tables. Afterwards, Mr. Peter guided me through the following tasks, although I still made some mistakes.

Mr. Peter also gave me some tasks to call the API and retrieve the users to compare the sync task logic. He also provided me the sample folder to refer writing logic tests. I’ll try to complete these tasks next week.

Conclusion

This week has been both challenging and insightful. I gained hands-on experience with applications and worked in multiple environments with different databases. However, every troubleshooting step and discussion with colleagues helped me gain the confidence to navigate complex architectures. Although I’ve encountered system errors and database connection frustrations, I’ll try my best.

Entity Creation for New API Project

Monday, November 4, 2024 – Last week,  which was a short week for me, I focused on building entities for our new API project. My first step was to review our entity-relationship diagram (ERD), a clear diagram we rely on for a clear visual structure of the database. This diagram, equipped with attributes and data types, serves as a reference point for any updates or improvements to the database. After double-checking data types and discussing potential enhancements with my colleague, I proceeded with entity creation within the project.

When defining entity models, I intentionally saved relationship configurations for last to avoid complications, allowing me to focus on careful assignments. After adding a migration, my initial attempt failed, so I reviewed and corrected some errors. Once the migration was successful, I moved on to developing CRUD operations, starting with a “Read by ID” query since it’s the most straightforward. Building the repository required extra attention as, unlike previous projects using EF Core, this one uses Dapper for database mapping, requiring SQL queries to be written manually. Since the entity I queried has a one-to-many relationship with another entity, I researched the practices for crafting SQL queries in such cases.

Before advancing further in the CRUD process, I created a unit test for the query. Running tests allowed me to debug and identify issues in my code and query. Mr Peter also provided valuable advice on tracing errors within the query based on error messages. By the end of the week, I successfully passed the test and plan to expand the test scenarios next week before proceeding to the next CRUD operation.

Streamlining the Seed Data Generator

Monday, October 28, 2024 – Last week, Mr. Peter assigned me the task of refining and to push the seed data generator that was previously created to automate sample data generation. Initially, the code was tailored for use only in my local environment, hence it required significant cleaning before it could be shared. Since I had been testing it extensively in a trial-and-error setup, there was quite a bit of redundant code to sift through.

To start, I revamped the UI page, removing unused buttons and giving it a more streamlined appearance. Then, I focused on optimizing the view model for better functionality.

The seed data generator was designed to handle multiple entities with a single button click, which led to long stretches of code that required careful verification to ensure smooth data generation. Although most of the functions leveraged existing code, a few necessitated extra queries. This meant creating new functions in a separate project, which hadn’t been pushed previously.

In my initial implementation, I used a parallel foreach loop to expedite data generation by processing multiple records simultaneously. However, this approach occasionally caused errors when handling more than two processes concurrently. Switching back to a standard foreach loop resolved these errors but slowed down the data generation, making the process less efficient.

Apart from needing Mr. Peter’s approval for certain functions, as I was limited to using DLL-based functions. Towards the end of the week, the generator worked well in my environment and everything was successfully operational, although further testing might be necessary.

Week 3 Internship: Creating New Page on POS System and Fixing Alert Duplicate Bugs

In the third week of the internship, Mr. Peter gave me a task to create a new page, which is the Return page. It’s all about uploading the reasons that customers return the products. We also had to add some functions, including delete, make changes, and search filtering. In the beginning, all the workflows I was working on were still good, all the API fetching could refer to other pages until I faced the searching and filtering problem. This was because the APIs provided by other pages allowed developers to call and search by query, but the Return Reason API did not have the searching function. I tried to solve this problem by myself, attempting to fetch data without sending a query to the API and instead searching and filtering locally so that it would not be influenced by network lag or latency.

After finishing this page, Mr. Peter asked me to find bugs related to what would happen if users deleted cookies manually and if the network was disconnected. Through these behaviors, I found that while deleting cookies manually, users could still edit data without logging in until the page refreshed. Additionally, after the network was disconnected, the website would pop up with a message saying “reading data null” as usual. Then, Mr. Peter asked me to do unit testing on the page I had just finished, but it seemed like there was something wrong with the Jest configuration. I’m still trying to solve it to ensure the tests can run successfully. Externally, I found that every time a user wanted to delete some data on the page, the website would pop up a confirmation dialog box, but after clicking confirm, the second alert that shows “data deleted successfully” would not appear. So, Mr. Peter asked me to find another alert component to replace the original to fix this problem.

In conclusion, this week was quite busier than the previous week because of solving a lot of bugs and creating new pages. I learned a lot from the experience of fetching real data from the API and working with it.

Create Tables and Unit Testing

Third week as an intern in Tong Hin. The task for the week is to do tables for users, tax and user’s address. At the start of the day, Mr Peter shared the repositories for the project. Creating tables is not hard but connecting the relationship took some time to think and code.

Most of my time has been used in creating unit test. To think about how a unit test can cover all the possible exception that might occur and learning to use breakpoint for debug. Debugging use lot of my time due to unfamiliar with debugging tool, doesn’t know how to trace back to the problem is and couldn’t understand the meaning of the exception. After Mr.Peter demonstration and some telling of Ms.Laili, I get to know the flow for debugging.

Ms. Laili has asked me for committing and pushing the code to Sourcetree. She showed me how to do it and the format for naming the commit and push. Beside that, she also teached me the content for the commit and push. I am happy with the environment of the company as it engaged me to continue learning.

In summary, the study week has been end at the previous week. It is working week starting onward and I am looking forward to it. The task for the week keep me busy. Hope that the weeks onward can also be fun for me.