π¦ Admin Web App (2021.10 ~ 2022.05) β
A newly created web app aimed at managing the settings for all products under Wevox. It also included a significant system architecture upgrade, migrating the frontend from a monolithic application to a Monorepo architecture and transitioning the backend from Ruby on Rails (monolithic) to a Go-based microservices architecture.
Issue π₯ β
As the number of products in Wevox grew, the monolithic application could no longer support independent development and deployment for multiple projects simultaneously.
Having a separate git repository for each project also made it challenging to create and manage shared assets across projects.
Goal π‘ β
Upgrade system architecture to support multiple projects independently developed and deployed
Release admin app as a sample project for the new architecture
My roles π· β
Team: 7 members in total, consisting of backend developers(3), frontend developers(3), and product Designer(1).
My primary responsibilities in this project focused on frontend development, after a lot of investigating, we decided to introduce Nx Monorepo to enable the management of multiple projects within a single repository.
I was responsible for:
- Reviewed legacy code and cross-checked new UI designs to ensure no features were overlooked.
- Collaborated with the designer to refine details such as loading styles, error case handling, pagination styles, and general form validation rules.
- Reviewed API designs to ensure they met requirements, addressing aspects like empty responses, initial sorting rules for lists, and error case definitions.
- Designed the Monorepo architecture, separating apps and libraries.
- Developed the frontend using Nx, Next.js, Material UI, and Axios.
- Migrated and refactored legacy code.
- Created reusable frontend assets, including shared UI components, shared functions, and shared state management solutions.
- Conducted code reviews to maintain code quality and consistency.
What achieved π β
- Upgrading the system architecture: enabling multiple projects to be developed and deployed independently, which significantly improved development efficiency.
- Established a new deployment process for frontend applications with the combination of Monorepo and CI/CD. Deployments for one project no longer trigger re-deployments for all projects, reducing release waiting times.
- The admin app served as a sample and documentation for the new architecture, facilitating knowledge sharing within the team.
If these could be improved β‘οΈ β
Although the project was completed in just six months and met its main goals, several challenges remained:
- Changes to shared libs had an unpredictable impact since there was no test coverage and version control of shared libs.
- The issue of page-based frontend presenters being too heavy continued, making it difficult to modify and test. This showed the need for clear separation between different parts of the system (domain, application, and infrastructure), so that changes and tests could be more controlled.
- The frontend was too dependent on APIs. Front-end is an app, not a view. We need to add mapper between API handler (request and response) and frontend data model.
- There was no standard approach to error handling (such as HTTP status codes and error codes), it was leading to confusion: an error sometimes is 400, sometimes is 500. We need the error cases definition based on domain not based on business cases.