Chapter 4: Crossing Over — From Backend to Frontend

After diving deep into the backed and understand how data truly flows. It was time to make everything visible.

⚙️ Angular Experience

After finishing the backend with simple logic, I moved to frontend to create a view. Well, this was a new whole story. As I mentioned in the previous chapter, my background was in the MERN stack, but for some reason, I switched to Angular.

Angular is a comprehensive framework. The first time I tried it, I found it quite easy to read because it clearly split the view and the logic. However, its docs and community posts are not as diverse as React’s. In some cases, finding solutions was difficult. and some tools could become outdated very quickly.

The hardest part when I started with Angular was RxJS, I had never learned the concept reactive programming before. It’s very different when from the concepts of Promises and Callbacks in JavaScript. I still struggle to fully understand it even as I write this. I only grasp a small part of the concept so far.

On the plus side, Angular sets up most of the tools I need when initializing a project, so I didn’t have to hunt for packages like I did with React. For UI components, I used Ng-Zorro, which is basically similar to Ant Design in React and very simple to use. You might ask, what about Angular Material? It’s a solid choice and widely supported, but it doesn’t provide pre-built components ready to use like Ng-Zorro. you need to customize a lot, and since I’m not very good at that yet. I choose Ng-zorro because I already had experience with Ant Design in React. That made using it faster and more familiar.

🏗️Building the structure

After initializing the project, it was time to build — but how? A house isn’t really a house without a proper structure. The same goes for a project: the folder structure matters. Unlike React, which is very flexible, Angular follow some rules but still allows flexibility.

Since I had limited experience with Angular, I spent some time researching best practices. I found two main approaches: one is feature-based, splitting folders by features, and the other is module-based, splitting into modules like admin, client, error, etc. I chose the module-based approach because I wanted to separate the admin layout from the client layout.

This setup made the project more organized and easier to maintain, especially as the app grew.

🔄 From building APIs to facing the frontend

Different from testing APIs with Postman — where you just send data and check the result — working on the frontend was a completely different story. In Postman, everything feels simple. You hit send, you see the response, and that’s it.

But in frontend, I had to take care of both sides — backend and frontend — and make them work together. It took a lot of time, image building the API first and creating the view after — every time I refactored the frontend, the layout change, the flow broke, and I had to fix things again and again. I realized that frontend work could easily take two or even three times longer than backend tasks.

Thankfully, after a lot of trial and error, I managed to get it done and upgrade the system faster than I expected. That was the first big milestone in this journey

🪜 First Milestone & Next Steps

The basic frontend is now fully structured and integrated to the backend

Next up: authentication and real user flows, which would take the app to the next level.