Why you should consider Monorepo and Nx for your project
Hi there! Have you heard of monorepos but don’t know what they are or whether they are suitable for your project? You are in the right place. Let’s start from the beginning.
What is a monorepo?
A monorepo is a single repository that contains multiple projects — including libraries and applications — with well-defined relationships in a single codebase.
The word “mono” often carries a negative connotation for developers because its immediate association with “monolith”, which is notoriously something to avoid in software development.
Besides the fact that monoliths are not just that bad if properly developed, monorepo approach encourages to write very modular code with a large set of reusable and independent libraries which is actually closer to microservices and microfrontends philosophy than monoliths.
Monorepos provides several benefits, including:
- Code reuse. Monorepos allow you to share code between projects, which reduces duplication and increases consistency.
- Simplified development. Developers can work on multiple projects without having to switch repositories, which streamlines the development process.
- Consistent tooling. Monorepos ensure that all projects use the same tooling and configuration, which makes it easier to maintain consistency across the codebase.
- Dependency graph visualization. Most tools that support monorepos offer some sort of graph view to quickly understand how the dependencies are structured between each application (or library) within the monorepo.
However, monorepos also come with some challenges, including:
- Increased complexity. Managing a monorepo requires a more complex setup, which can be difficult to maintain and understand. But the return of investment will come soon enough and monorepos tools such as Nx continuously strives to improve the developer experience and make it smoother and smoother.
- Increased build times. With multiple projects in a single repository, build times can increase, which can impact development speed. However, that is tremendously alleviated by caching and common mechanisms to detect what code actually changed to trigger the build of just the affected projects.
Is monorepo suitable for your project?
Monorepo is a tool, and as such, there are some use cases where it shines and others for which it is not particularly suitable. Let’s find out if monorepo is appropriate for you.
Does your project have multiple front-end and back-end projects?
For instance, if you are developing a social media platform that has a web application, a mobile application, and a backend API, a monorepo is a perfect match. This is because the codebase for each project can be entirely different, but it’s still easier to manage them in one place, share dependencies, and possibly common libraries.
Does your project have a lot of shared code between applications?
If you’re developing a cross-platform application that shares common code, then a monorepo can be an excellent choice. For example, if you’re developing a mobile application for both iOS and Android, you can have a single codebase that is shared between both platforms. This approach can significantly reduce development time and reinforce consistency.
Does your project need a high level of modularization?
Such projects typically have many modules that need to work together. In these cases, a monorepo can help a lot as it allows developers to work on multiple interdependent modules simultaneously without having to switch repositories.
Does your project require consistent tooling and configuration across multiple teams?
If you’re looking for consistent tooling and configuration across different teams, a monorepo can come to the rescue. In fact, with monorepo all your projects are in the same place, can share commands, tools and configuration files. You will naturally be inclined to define standards and common practices across teams to not make your codebase a total mess.
Does your project involve enterprise applications with multiple teams and departments?
In such cases, definitely consider building up a monorepo. This is because it allows all teams to work on the same codebase, which can significantly reduce duplication and ensure consistency across the project — provided that the teams do not lack discipline!
Is your project small?
If you’re working on a small project that doesn’t have multiple projects or modules, a monorepo may be overkill. If you are not familiar with monorepo yet, there probably aren’t enough reasons to begin now. However, if you are already acquainted with monorepo in the past and your small project has the potential to grow and scale, or maybe other projects could possibly come along in the near future, don’t discard the idea to start off with a monorepo.
Does your project include applications with a strong separation of concerns?
If your project consists of applications and libraries that are very independent from each other, the reasons supporting the adoption of a monorepo are very scarce to be honest.
Does your project require separate version control systems?
There is a chance that different applications/modules in your project require separate version control. In such cases, you probably should avoid monorepo and go with the classic polyrepo approach.
Does your project use entirely different technology stacks?
If you do not have the chance to share code and dependencies between applications due to completely different technology stacks, it may not make sense to use a monorepo. For example, if your back-end is written with Spring and your front-end is built with React. Nonetheless, if you are using tools such as OpenAPI Generator, you could still consider using a monorepo for sharing the api specification file and the generated layer of models and controllers provided by the tool.
Which tool should I use?
At this point, you may have realized that a monorepo is a good fit for your project — or at least I have caught your attention because you see potential in it. But, maybe you’re wondering: “Okay, it all sounds amazing, but how does it work in practice? Which tool should I use?”
There are a plethora of tools out there, such as Nx, Turborepo, Bit, Lage, Rush — just to name a few. My piece of advice is to go with Nx in conjunction with your favourite package manager.
If you have heard of Lerna, you should know that Nrwl and the Nx team took over stewardship of the project a few months ago. Although the project is not dead by any means, with a new release and a strong roadmap published, it is likely that the two tools will not coexist for long and Nx will eventually prevail.
As you probably already know all the most relevant package manager (npm, yarn and pnpm) support the workspaces feature which basically enables to manage dependencies from multiple package.json — for every application/library — within a singular, top-level node_modules.
This is really the basis of your monorepo setup and it’s already wonderfully built-in in your package manager! On top of that you can make things more sophisticated and efficient adding up Nx.
As your monorepo grows, thanks to Nx, among other things, you can:
- Run tasks only on the packages that changed using
nx affected. - Use advanced caching based on file contents to avoid running anything that was already computed before.
- Use remote distributed caching to speed up your CI — Nx Cloud.
Conclusion
Now you should have a better understanding of what a monorepo is and why you should take it into account when starting a fresh new project — or when you’re thinking about a heavy refactoring of an existing one. We’ve seen that monorepos provide code reuse, simplified development, and consistent tooling. But with great power comes great complexity… well, at least in the beginning, that’s for sure!
Finally, if you want to get your hands dirty there’s no better place to start than NX getting started. Enjoy coding!
Last but not least, I would like to thank you for having come this far. Hopefully, you have learned something new to use in your daily work. I would really appreciate your feedback in any form you like — comments, claps, messages, letters delivered by carrier pigeons, and so on and so forth. If you liked this post and want more, don’t forget to start following me and subscribe to my newsletter.
