What is Monorepo?

A monorepo is a repository that can be used to host multiple packages encapsulating all projects across the organisation. These packages are isolated and can be meticulously and independently upgraded without tinkering with any dependencies. A version-controlled code repository enables seamless and simultaneous integration of changes without being constrained by the projects' or packages' conflicting version histories.

In Karza Technologies, we have many products such as Lead Generation, KScan, Total KYC, Video KYC, etc. We have created a separate folder for each project, and about 30-40%% of all the code is the same across all projects, including module 1, module 2, and module 3. As an example, in multi-repository systems, in which there are multiple repositories for all projects and one repository has only one project, there may be clones of the same code across many projects, as well as duplicates or multiple copies of the same code, which prolongs the process of publishing and running each project and increases the effort. 

As there is a different codebase for KScan and Total KYC, if we added a feature in KScan, we would have to manually copy and paste the code in TotalKYC, which would take a lot of time and effort as the feature may not be compatible with TotalKYC's version history, thereby requiring monumental changes.

Monorepo has a parent folder called the workspace. All the project folders are located in the workspace. Each project consists of modules. Furthermore, all projects in the workspace share a set of standalone libraries. The workspace contains multiple shared libraries having codebases common to all projects, such as one for module 1, another for module 2, another for module 3, etc. Consequently, the codebase can be used across all projects in the workspace without requiring any changes to the projects' codebases, seamlessly incorporating changes into the projects.

Advantages of Monorepo

Visibility 

Everyone has access to everyone else's code unrestricted. As a result, developers in different teams can engage in intriguing discussions over a problem statement, leading to cross-pollination of ideas and cross-collaboration. A holistic solution can be reached by considering all the contrasting viewpoints and opinions. Another developer can spot a bug in another project that the other team did not even know existed and fix it. 

As a result, teams can avoid working in silos, unaware of how their projects contribute to the organisation's overall efficiency. Instead, they can visualise all the dependencies in the project pipeline, which ultimately leads to the organisation's smooth operation. It also motivates the developers because they can see they are not working on a random problem statement but developing code that has a noticeable impact, not just on the operations of an organisation but also on the bottom line as well as the top line. 

Consistency

Companies often deliver starkly different user experiences across all front-end interfaces. This is because each team goes their own way without communicating with each other. Each team's diverse perspectives and ideas result in inconsistencies in features and functionality across different interfaces. As a result, functionality and features are not integrated across interfaces. Consumers may lose confidence in the product and be unable to use the app across different devices flawlessly, resulting in chaos and confusion. Monorepo improves consistencies and enforces code-quality standards with the codebase all in one place.

Atomic commits

In the case of a critical bug or breaking change in a shared library, the developer must set up the tools and the continuous integration environment to apply the changes across multiple repositories with disconnected revision histories to fix the issue. In addition, it is challenging and cumbersome to coordinate the versioning and releasing of packages. Monorepo eliminates the need to make a pull request for large-scale refactorings for every repo. Through an atomic pull request, you can enable changes to be made to several packages in one commit. In the long run, such features help save a lot of time and effort and considerably enhance maintainability.

Easy sharing of code

You'll probably need to create a repository for shared code if you want to share code across repositories. You will need to set up the tooling, configure the continuous integration environment, add commiters to the repository, and publish packages so that other repositories can rely on it. In addition, reconciling incompatible versions of third-party libraries across repositories is a humongous, tiresome task. Building a repository of shared code with Monorepo allows you to easily share code and publish packages without worrying about incompatibilities due to conflicting versions of third-party libraries. Due to Monorepo's version-controlled code repository, all projects adhere to the same version with the same revision history, making the same version of third-party libraries applicable to each project.

Dependency Management 

Companies working with various components face the challenge of managing dependencies among them. You can easily visualise all dependencies between different components in Monorepo, eliminating the need for a package manager to identify dependencies and link disparate projects across multiple repositories. The first time you start a project, you will most likely develop a shared code repository. The shared code library package will undergo frequent changes. By using Monorepo, you can update and refresh all codebases simultaneously. The advantage of Monorepo is that each component receives the latest version of the shared code. In addition, updating dependencies doesn't require reinstalling them in each repo. 

Disadvantages of Monorepo

Though monorepo has certain advantages, it also has certain disadvantages that preclude it from being a fit-for-all solution:

Dependency Mismanagement 

Eventually, the ability to version the shared libraries will become necessary as the application matures. There may be components of the application that do not need to incorporate the new changes, and they should not be forced to update their code. However, in a monorepo, you will always have to update the code even if it is detrimental to its function. Team organisation matters, too. Monorepo doesn't pose a problem if there is a single team that knows all the codes and dependencies. Typically, monorepo contains logically independent projects from different teams, so tightly coupled dependencies can be problematic. The code vital to your project's effective functioning has been altered without your knowledge or violated your team's code.

Violation of single-team ownership principles

Several companies adhere to or follow the concept of single-team ownership. The ownership of a service, system, module, or component should be vested in a single development team. Those responsible for this component should take care of all aspects of it - designing, coding, testing, deploying, operating, supporting, and fixing it. This model includes accounting for all the changes in the component's source code by that single team. This does not mean that only the team members possess indomitable power to revise the code; instead, it means that the entire gamut of changes made to the component is solely the responsibility of the team owning it. All changes must be reviewed and approved by the owning team. As the component's code is ultimately their responsibility, they must be able to manage it.

This is incredibly hard to enforce if all components' source codes are encapsulated in the same depository. It is impossible to maintain ownership and integrity of the source code of your component if your source code and the source code of your siblings are all located in the same repository with the same access permissions, check-in procedures, and approval capabilities.

No way to restrict access to certain parts of the component

Unfortunately, you cannot share only part of your Monorepo- you will have uninhibited access to the whole codebase, which can lead to security issues.

Conclusion

Tech companies are rapidly transitioning from polyrepo to monorepo, inspired by their contemporaries like Facebook and Google, which have documented the incredible benefits and convenience it offers. There is still a long way to go before we see how it will transform the tech industry unprecedentedly.

About us:

Karza Technologies is the largest data, analytics, automation, and decisioning solution provider to FIs, catering to the entire lending lifecycle from onboarding to diligence & monitoring to collections. Karza Technologies solutions enable systemic fraud prevention, risk management, compliance & automation through superior data engineering and deep tech applications.

In a nutshell, Karza stands on the trifecta of digitization: automation, enhanced diligence, and robust decisioning for straight-through processing; thus, creating a state-of-the-art digitization process without compromising on security and quality. Karza Technologies is a pioneer in the services it offers and has successfully acquired a very diverse portfolio of 300+ live clients, spanning across the largest gamut of use cases in the industry.

— — — — — — — — — — — — — — — — — — -

Write to us at connect@karza