Story of a Developer who Regretted Not Choosing Monorepo and Nx

Story of a Developer who Regretted Not Choosing Monorepo and Nx

All illustrations have been generated by MidJourney AI specifically for this article :)

Chapter 1 — The Exciting Adventure Begins

As our daring developer embarks on a new quest to build an app, he starts with a simple frontend application, focusing on a clean UI and user experience. At this stage, the monorepo concept might seem like an overkill, but the developer is about to discover the benefits of this approach in the chapters to come.

Chapter 2 — The Backend Twist

Our developer progresses and encounters the need to consume a public API, but alas, it requires modifications. Fearlessly, he created a separate repository with a Node.js backend to craft a proxy API for the frontend. This backend repo houses the logic for HTTP requests, response processing, and data communication with the frontend.

Chapter 3 — Duplication Struggles

While working on both apps, our developer stumbles upon a growing issue — code duplication. Both frontend and backend apps share the same data models and validation logic. To avoid the curse of maintaining two sets of identical code, our intrepid developer opts to create a shared library.

Chapter 4 — The Shared Code Rises

To combat duplication, the developer forges a shared code repository containing the common code needed by both frontend and backend apps. This repository transforms into an NPM package, sharing data models, validation logic, and utility functions across both apps like a bridge between two worlds.

Chapter 5 — Juggling Repositories

As the app evolves, managing multiple repositories becomes a complex dance. Keeping the NPM versions synchronized in both apps turns into a tedious task. Our developer craves a simpler, more efficient way to streamline his development process.

Chapter 6 — The sudden need for a Mobile App

The app’s popularity soars, and the users voices echo the demand for a mobile version. Our developer takes up the challenge and sets out to create an Ionic mobile app that harnesses the power of the existing backend API and shared code.

Chapter 7 — Giant weight starting to crush

To bring the mobile app to life, the developer spawns a new repository for the mobile app code. This app must utilize the same backend API and shared code as its frontend counterpart. Consequently, the developer now finds themselves maintaining a quartet of repositories: frontend, backend, shared code, and mobile app.

Chapter 8: The Struggle of Tedious Maintenance

Juggling multiple repositories becomes a time-consuming, error-prone endeavour, particularly when maintaining numerous CI/CD pipelines. Our developer realizes he must refactor his codebase with the monorepo approach and Nx Devtools. This way, he can manage all his code within a single repository, slashing the time and effort needed to maintain multiple repositories.

Chapter 9: A Journey to Modularity

During the refactoring odyssey, the developer uncovers the hidden coupling lurking in their code. He ventures forth, refactoring the app structure to foster modularity and decoupling. Nx Devtools and Monorepo pattern becomes their trusty tools to create libraries containing the shared code used across the app. This modular approach paves the way for easier maintenance and code reuse throughout the entire application. Module Boundaries rules make sure everything stays in the right place.

Chapter 10: The Moral of the Story

The saga concludes with the revelation that Nx Devtools and the monorepo approach can propel app development to new heights of efficiency and manageability. By breaking down and unifying code in a single repository, developers can save time, minimize errors, and streamline their workflows. Nx Devtools empowers developers to elevate their app development process, simplifying the journey from start to finish.

Even if you are not planning to have multiple apps straight away. It doesn’t cost you anything to start your journey with monorepo. Nx provides options for standalone apps as well. I cannot find an argument that would prevent me from starting with it every time.

Can you? Let’s discuss :)

I hope you liked my article!

If you did you might also like what I am doing on Twitter. I am hosting live Twitter Spaces about Angular with GDEs & industry experts! You can participate live, ask your questions or watch replays in a form of short clips :)

If you are interested drop me a follow on Twitter @DanielGlejzner — would mean a lot :). Thank You!