Dealer Fleet Management Dashboard

Overview

This was an agency project to build a fleet management dashboard for automotive dealerships. It allowed them to view the status, maintenance history, and any service warnings for vehicles out in the field so they could proactively contact customers for service appointments.

I came into this project towards the end of its development cycle and was primarily tasked with refactoring and cleaning up the frontend and fixing bugs to prepare for client handover.

Tech Stack & Architecture

• Angular
• Express
• Laravel
• Microservices
• PostgreSQL
• OpenAPI
• Kubernetes
• AWS

This project was quite large and had 2 frontends (main and admin), 2 primary backend APIs, and over 20 microservices.

Key Features

• Dealer dashboard
• Admin panel
• Vehicle monitoring
• Vehicle reporting
• Tire measurement

Challenges & Learnings

This was a large and complex project that I had to onboard to quickly and start refactoring and fixing bugs to get it ready for client handover. There were over 3k source files and nearly 200k lines of code to work with spread across many services written in either typescript or php. I spent some time first understanding what the project did, then started looking at how each application/service was composed, then got started on fixing bugs. One of the easiest ways to understand a codebase is to start running it and working on it so I chose some bugs which would help investigate the various services.

A big learning from this project was appreciating some of the problems with microservice architecture. It contained some microservices that were quite nice which had clean separation of concerns, acted independently of other systems, did one thing and did it well, etc. There were other microservices that due to time pressures were tightly coupled to other services. Tracing the flow of operations through 8 different microservices to identify the source of a bug was a strong lesson on how important it is not to build a distributed monolith.

Deciding to use a microservice should be an intentional, thought-through decision. A modular monolith approach can often give the same benefits of clean interfaces between modules without the extra HTTP or infrastructural complexity. Keeping things simple encourages clean code and maintains developer velocity.

Another big learning was how awful Sequelize is as an ORM, especially when it is implemented in different ways in multiple microservices by different developers. Following this project we opted to use TypeORM for future projects and I helped develop standardised approaches for defining entities, repositories, and migrations which is a much nicer way of working with a database.