Ever felt like your codebase is scattered across a million different repositories? That’s the life of a polyrepo, the traditional way of managing software development. But what if there was a better way? Enter the monorepo, a single giant repository housing all your projects and libraries.
This article dives into the world of monorepos, explores their benefits and drawbacks, and introduces NX, a powerful tool built specifically for managing these code havens.
Monorepo vs Polyrepo: Collaboration vs. Isolation
Imagine a world where each development team has its own code kingdom — a separate repository for every project. This is the essence of a polyrepo. While it offers autonomy (each team makes its own decisions), it can lead to isolation. Changes in one project might break another, simply because they haven’t been tested together.
Monorepos flip this script. They bring all your code under one roof, fostering collaboration and ensuring everyone’s on the same page (literally, in the same repository). But wait, doesn’t that sound like a tangled mess? Not quite. Monorepos allow for well-defined relationships between projects, keeping things organized even within the one big codebase.
But before you jump ship to monorepo land, remember — it’s not for everyone. It works best for organizations with a shared codebase and a strong focus on collaboration.
Monorepo Myth Busting: It’s Not a Monolith!
Don’t confuse monorepos with monoliths. Monoliths are giant, tightly coupled applications where everything’s intertwined. Monorepos, on the other hand, can house independent, loosely coupled projects. Think of it as a library full of books — each book is a project, but they’re all neatly organized on the same shelves (the monorepo).
Enter NX: Your Monorepo Management Superhero
So, you’ve decided to explore the monorepo world. Here’s where NX comes in. It’s a build system specifically designed for the unique challenges of managing these large-scale codebases. NX boasts a toolbox of features to keep your monorepo running smoothly:
- Parallelize Your Workflow: Speed things up by running tasks simultaneously. No more waiting for one build to finish before starting another. Learn more here
- CI Powerhouse: Improve your continuous integration performance by distributed task execution across multiple virtual machines.
- Cache Like a Boss: Avoid unnecessary rebuilds with local and remote caching. Only rebuild what needs rebuilding, saving precious time.
- Tame the Test Beast: Split large end-to-end tests across VMs to identify and re-run flaky tests more efficiently.
- Plugin Power: NX plugins extend its functionality. Generate code, automate dependency upgrades, and enforce best practices across your organization.
The Final Verdict: Monorepos with NX — A Powerful Duo
Monorepos offer a compelling alternative to the traditional polyrepo approach, fostering collaboration and reducing the risk of breaking changes. NX, with its suite of management tools, empowers you to take full advantage of the monorepo model.
However, remember — monorepos aren’t a one-size-fits-all solution. Consider your team structure and development style before making the switch. But if collaboration and streamlined workflows are your goals, a monorepo managed by NX might just be the key to unlocking a new level of development efficiency.
Top comments (9)
Just be SOLID, and stick to contracts ;o)
And let's forget all this "DevSecOps" rubish, why are we using tools, after all. Just stick to good practices and magic will appear ;)
All that dev...ops stuff has nothing to do with SOLID principles ;o)
Sorry, maybe you did not get the sarcasm, or maybe I did not express myself correctly enough for you to see the common point, which is a little bit "second degree", as English is not my native language.
Of course, I know Devops and Solid have nothing to do : I shouldn't be allowed to express anything about CS or IT for the rest of my life, if I did not know that and dare to open my mouth to comment anything on this site ! I should even go to jail if it was for me to decide ;o)
I'm a chief software engineer and architect in a very big company, and I'm teaching SOLID and clean architecture in this company "Learning Academy"....
And most of the teams I lead know my pseudo here :) .
My point is that devops is all about tooling, and this tooling is here mainly to check that this point (good code practices), or this other point (security practices and wasp top ten) or ...any point...has been correctly implemented, respecting the ...rules .
Which means, if we except the automation part, devops is nothing else than a set of tools for checking well-defined, well-known and commonly accepted rules. SOLID is nothing more than another set of rules, that, in my experience, nobody really understands (especially the Single Responsability principle and the Liskow Substitution rule, unfortunately always explained with this very bad Rectangle/Square analogy). And here, I'm speaking about people who know that D is dep. inversion and not injection ....
By the way, using Nx and all the tools it provides drives you far, far above following SOLID and Interface contracts. It makes you think SOLID, by implementing your own dependency rules and thinking about their relationships on one, two or n dimensions. It forces you to redefine those rules, so day after day your thought and your mental model is reorganized, not on "theoretical rules", but just on a practical very pragmatic level.
It's as simple as this : If you don't understand, think and set the right rules, it does not work and your construction fails right away, you just see it literally when you ask Nx to show your deps diagram.
I won't go on further on this, but, just to take one very simple and comparable example . If you have an OPEN API spec, would you prefer to write all the client code by hand, or use a generator (that you can write for yourself if you wish), to generate it in any language (as you work at the AST level, which is what Nx tooling is offering to you) ? You speak about Interface contract . What is the most secure option ? Having your client upgraded automatically from the swagger url or modify it after you received an Email with the new interface API ?
Nx offers you a very rich existing tool set , and a very smart API to use and write any tool you need, to generate code from specs or templates (generators), or to execute complex scripts with parallelization and asynchronicity (executors).
After about five years of practice, I can tell you that, for my own point of view, any project that is more complex than a POC or a demo application will benefit, in a way or another, of all the possibilities Nx brings to you.
To finish my loooong comment, I think it's important to make a point : Nx is perfect for monorepo horizontal management, but you don't need to use a monorepo to get advantages from it.
By the way, the four "main" tutorials in the entry level doc are showing how to use Nx with one Angular app and one React app using, or not using a monorepo approach.
Thank you.
P.S. I'd hardly durst delegating generation ofAPI to any automated tool - it hardly knows how it works.
I really understand your point, and I respect it, because I'm coming from a pure "backend" background, where we were even writing our communication protocol over TCP/IP, so any tool that was not written by us was evil to our eyes :) ....but the good thing is that you are able to create the template; or even the parsing script yourself. The tool just loads the OPEN API spec file, then parse it, and, depending on how it's implemented, you have an AST or a node collection (i.e. something that resembles an object tree structure, more or less), and now you can do everything you want from this point : use a template or not (if you want to automate some very repetitive operations, and have a client service which follows a predefined structure _ all the GET operations, then the POST, ..., each section organized from the parameterless methods to the one that have the longest parameter list, etc ....), generate all the DTO types and even the mappers/adapters to your view models if you have some (within an angular monorepo, we even generated the store fill and update operations, so our UI layer did not have access to the HTTP API methods, and our (smart) controls were only working with private services that accessed the store generated methods, as I wanted the store to be the only accessible source of data, and the way it's done lays in your hand and brain.
The tool is only automated is you want (as you can choose to regenerate before each build to make sure you're always in sync), but the really nice part is the it's YOUR tool, you can start from well known tools like open api gen , or swagger gen (the templates are fully customizable using the "handlebasr" syntax, or you can start from scratch.
In our case, what Nx is bringing to you is a lot of tools, and/or apis, plus a very smart build system and abilities to decouple your architecture : you can consider that your app is just the "main" entry point, and create everything else as "little units of functionnality" for which you can create tags and types, saying this "lib" is an utility type , and this other one is a "UI" type, and then set a rule that says that utilities "libs" can never reference "UI" libs , as obviously you don't want your 'Math' lib to have any dependency on a UiControl.
So, i really think that if you are involved (and it seems to me you are) in ways to improve your code and architecture, it's really valuable to dedicate 1 hour of your time to fully understand what Nx is and offers.
It is NOT just for monorepos, and it can bring improvement in any area you are concerned with : architecture, build system, Ci/CD, aspects ....you name it.
Just to say, it's now a big thing, but it started as a project from Victor Savkin (IMO he's really not far from a genius in the way he is seeing things) and Jeff Cross, who were the main tech lead and architect of Angular2+, (the most delicate part of the engine were written by V. Savkin), but then they left Google to start their own company, Nrwl (the company that supports Nx), and despite its very high quality standard, everything they were publishing was totally free for years (now they have enterprise plans) and is still open-sourced .I think everybody will learn something in just reading about the Nx ecosystem. It's not a new tool or framework, for me it's a lot more than this, a kind of new paradigm and create way to think about your code.
Of course, it really shines when you need to work with different teams at the same time, each team dedicated to an app in the monorepo, or to a feature of one app, and with a trunk base git flow it offers you some possibilities to organize your work (for instance, by design, it leads naturally to a very good practice of doing three different levels of code review : one at the feature level from the team lead dev, one at the app level from the app lead tech and one at the main/monorepo level from the chief engineer/architect).
But even for small teams, and/or just one developer, it has many treasures to offer.
DISCLAIMER : I don't have ANY share in Nrwl capital, I'm just totally in love :=)
So have a nice day, my friend, and feel free to share your point of view about it if you have some time to dedicate to Nx.
Hi Ingila Ejaz,
Thanks for sharing.
Thanks for the informative post! Could you elaborate on how NX handles dependency management in a large monorepo?
Just take a look at their "enforce-module-boundaries" EsLint rule, and you'll have a very good starting point to understand this topic.
I'm using Nx for more than five years now, and it changed everything in the way I architect apps, from simple Front-Ends, to MFE, to complex distributed systems (Nx is language and platform-agnostic, and if you don't find a plug-in for your stack, you just need to know a little bit of ES6+ or Typescript and use their API to write one that suits your needs).
As you can (and must) read in their docs, using Nx drives you to a whole different mental model when you think about your system. After a little bit of practice, you naturally think in a "Modular Clean Architecture" way :)