This content originally appeared on Bits and Pieces - Medium and was authored by Ashan Fernando
Whether you do Microservices or Microfrontends, many developers still stick with Monorepos. And what makes it so challenging to move away? Let’s find out!
In the world of software development, the debate between monorepos (monolithic repositories) and multirepos (multiple repositories) is ongoing. A monorepo is a single repository that houses the code for multiple projects, including microservices, microfrontends, or even different applications.
Despite the rise of microservices and microfrontends architectures, many developers and organizations continue to stick with monorepos. This article explores the reasons behind this persistence, the challenges of attempting to move away from monorepos, and the options available if you need to gradually shift away from it.
Why it's so Difficult to Move Away
Despite their limits, developers tend to stick with monorepos. Several reasons affect this decision.
The Comfort of the Known Realm
Picture this: a seasoned developer opens their IDE and is greeted by a familiar, sprawling codebase. This monorepo is predictable, comprehensive, and all-encompassing, like an old friend. It contains everything from core services to minor utility scripts. For many, this is the world they’ve grown accustomed to. Fragmenting this well-known landscape into multiple repositories feels like venturing into uncharted territory.
Besides, the familiarity of a monorepo offers a significant comfort factor. Developers who have spent years navigating a single repository have a deep, intuitive understanding of its structure. This familiarity reduces cognitive load, allowing them to focus on coding rather than constantly switching contexts between different repositories.
However, for larger software teams, things get more complicated. We break things into manageable pieces to give each team autonomy for developing and releasing new features.
We define boundaries for code and agree on who owns what. This can be easily done with multiple repositories. Yet, for the majority breaking away from monorepos isn’t an option.
Collaboration and Code Sharing
Collaboration is key in large teams. Monorepos makes this collaboration seamless. Imagine a team working on a large-scale e-commerce platform. The microfrontends and various microservices all live under one roof. A developer working on a new feature can easily find, share, and reuse code across the entire codebase. Code reviews become more straightforward as reviewers can see the impact of changes across the entire system.
There’s no need to juggle multiple repositories or worry about inter-repo dependencies. Moving to a multirepo setup would require new systems and tools to facilitate the same level of collaboration, introducing additional complexity.
But is there any other ways to track code changes in addition to repositories? Can we track changes one level up (like modules or components)?
Visibility into the Big Picture
Another advantage of monorepos is that it’s easier to see the big picture. Developers can understand the high-level boundaries of the system as they are organized into different directories.
This visibility is especially beneficial for onboarding new team members. Instead of navigating a maze of repositories, new developers can explore a single codebase, making the learning process straightforward.
However, in a monorepo, visualizing how different components are interconnected can be challenging. Developers must invest additional effort and use specialized tools to map out these relationships. Without proper visualization, it’s easy to lose track of how different components interact, leading to potential integration issues.
On the other hand, in a multirepo setup, the problem is compounded. The fragmented nature of multirepos can obscure the overall architecture, making it harder to understand how different pieces fit together. This can slow down development can lead to miscommunication and errors, further complicating the development process.
Effective visualization tools and practices are essential but can be difficult to implement consistently across multiple repositories.
Access Control and Ownership
In a monorepo, managing access control is a double-edged sword. On one hand, having a single repository simplifies permissions management. On the other hand, it can lead to complications in defining who has access to what parts of the codebase and who owns specific components. Without clear ownership, developers might inadvertently modify parts of the codebase they shouldn’t, causing potential conflicts and integration problems.
This lack of clear ownership can lead to a “not my problem” mentality, where developers ignore other directories in the repo, focusing only on their areas of responsibility. This can result in less modular and more tightly coupled code with code duplication.
On the other hand, establishing clear ownership and access control policies in a multirepo environment requires careful planning and ongoing management. However, this is one of the main motives for seeking multirepo solutions.
Not Knowing the Alternatives
Despite the challenges posed by monorepos, the alternatives are not always appealing. Sometimes, it’s difficult to think outside the box and consider the other alternatives available to manage large code bases effectively and empower collaboration.
Returning to my original question, “Are there other ways to track code at a higher level?” Two approaches exist. One is to define code libraries, where you track each version as a package, and the other uses Bit components. Sin
Monorepo to Multirepos with Bit
Since you are already familiar with the concept of libraries and packages, let’s look at Bit in detail and how it can alter how you structure your code for the future, regardless of whether you use a monorepo or a multirepo setup.
Composable Software Architectures are Trending: Here's Why
Bit is a build system for composable software. It makes the composition of applications from independently versioned components seamless and fast.
The core innovation of Bit is the Bit Component, a container for composable software components. You can think about it as a next-generation package. It is extensible, portable and seamless to maintain.
Bit component can be a UI component (e.g., a React Component), a NodeJS module, or even a piece of documentation.
If you migrate your code into a Bit component, each has a boundary with its dependencies, so you can develop and test it independently from other components. It is also tracked outside the repository in bit.cloud so that you can import a component and contribute back anytime. You can set up CI/CD for components so that once you modify a component and commit to the repository, it will be exported to the cloud and made available for any other team.
By connecting all the dots, Bit visualizes the dependencies across different components so that you see the big picture, regardless of the repository where the code is being tracked.
All these features together provide a complete ecosystem for creating modular code bases. This makes your code base flexible enough to move from monorepos to multirepos if required.
The best thing is you can move a component from one repository to another since each component is independent from one another (not having relative paths).
Conclusion
Despite the rise of microservices and microfrontends, many organizations continue to use monorepos due to their familiarity, ease of collaboration, and the challenges associated with moving to multirepos.
And, build systems like Bit, helps to overcome this by providing a flexible structure to your code base by breaking it into more granular components. Since these components are flexible to move between repositories, deciding to move away or stick to a monorepo becomes a viable option.
And, if you see any other alternatives that help structure your code to tackle challenges with monorepos and multirepos, share them in the comments below.
Thanks for reading! Cheers!
Learn More
- Monorepo, Poly-repo, or No Repo at all?
- Bit Components: The Web’s New Building Blocks
- Integrating Bit into Your NX Monorepo: A Developer’s Guide
- Integrating Bit into Your NX Monorepo: A Developer’s Guide
- Monorepo vs Polyrepo: 5 Things You Should Consider
Monorepos: Why it’s Difficult to Break Free was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Ashan Fernando
Ashan Fernando | Sciencx (2024-06-25T16:47:41+00:00) Monorepos: Why it’s Difficult to Break Free. Retrieved from https://www.scien.cx/2024/06/25/monorepos-why-its-difficult-to-break-free/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.