Lessons learned while moving our Frontend to a Monorepo
Unmudl and TuringTech's experience moving Unmudl's frontend to a monorepo.
Unmudl and TuringTech's experience moving Unmudl's frontend to a monorepo.
I joined Unmudl as a full-time CTO in July 2021, that is when Turing Technologies inherited our dashboards/portals from an outsourced dev team. During the initial technical audit, TuringTech's lead Sarmad Kazmi was appalled to know that out of four portals, three were made in Angular and the fourth one in React. These were maintained inside three separate repositories each with different coding practices, dependencies and style. The angular portals were made on top Bootstrap Angular while the React one was made on top of Ant Design. This created a lot of confusion and a very steep learning curve among TT's team. Fixing a small bug/issue was painstakingly slow and took days to reach completion. This also created a recruitment challenge, to maintain three separate portals required at least one full-time Angular engineer, while a new team was being built to re-platform the frontend in Next.js.
In principle, there is nothing wrong with using different JS frameworks for different parts of the applications, however in case of a pre-seed funded SaaS company (as we were back then) actively fundraising, this was nothing short of a catastrophe and could've led us to premature failure, as the tech wouldn't be able to catchup with requests.
There were major design inconsistencies as well which didn't sit well with our design team, it would require our team three times the effort to do a small improvement. I'll illustrate this in detail below.
Three out of four portals divide the address from Google Places into city, state and country while displaying the complete address inside the main location field, while one was using the Google Place ID inside a single field to fetch the address every time the the request was received.
For example: when we tried to add floor number with the location, this took 2 engineers (one Angular and one React) to go through three different repositories and four portals to do the EXACT SAME THING, which in a perfect world should've been done by one engineer from inside a single folder. Hence, a solution that ensures a single source of truth became my topmost priority while considering potential solutions for re-platforming our frontend.
These design inconsistencies were present all across the project which took a toll on our engineering team. I am truly grateful to Haseeb Tariq for initially maintaining the portals and ensuring the issues were resolved on time, and later Ureesh for using his rusty Angular knowledge from his college days to maintain the legacy portals for the past few months.
We considered two options:
Before making a final decision, I did some research of my own and came across this excellent talk at Uber Technology Day in 2017.
I explored products from companies which (I assumed) might've encountered the same problems as us due to different dashboards/views for different users and providers. While exploring UpWork, I noticed /nx in their URLs.
We studied directory and code structure of Shopify's Polaris, Wise's Neptune and Polarwind by Envoy. Later we designed our own structure which would be more suited to our use case.
Some of the advantages we've already noticed are:
As we further build our product, we're hiring rockstar engineers to join Turing Technologies and come work on Unmudl. Our frontend is built on:
Checkout Turing Tech's careers page for more information: