π¦ Admin Web App (2021.10 ~ 2022.05) β
Issue π₯ β
As the number of sub-products 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 π‘ β
Admin app was a newly created web app aimed at managing the settings for all products under Wevox.
Through the admin app, we upgraded the system architecture to support independently developed and deployed multiple projects. It also included a significant system architecture upgrade, migrating the front-end from a monolithic application to a Monorepo architecture and transitioning the back-end from Ruby on Rails (monolithic) to a Go-based microservices architecture.
My roles π· β
Team: 7 members in total, consisting of back-end developers(3), front-end developers(3), and product Designer(1).
I primarily focused on front-end development in this project. After extensive investigation, 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 front-end using Nx, Next.js, Material UI, and Axios.
- Migrated and refactored legacy code.
- Created reusable front-end 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 front-end 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.
- Found the colleagues who thought there were still a lot of things we could improve after this project was completed.
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 front-end presenters being too heavy persisted, which made modification and testing difficult. This showed the need for clear separation between different parts of the system (domain, application, infrastructure and UI), so that changes and tests could be more controlled.
- The front-end was too dependent on APIs. The front-end should be treated as an application, not just a view. We need to add mappers between API handlers (request and response) and front-end data models.
- 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.