Ending Monorepo Vs Polyrepo Debate
Component-driven development and micro frontend architecture are the two most sought after ways to build scalable frontend during web app development. The crux behind both these approaches is to break down the frontend into smaller entities. One method enables you to achieve this through smaller components while the other has the provision for building micro frontends.
While both these approaches offer a great deal of flexibility and scalability to your frontend, they also leave you with a lot more moving parts compared to what you’d have on a conventional frontend monolith. With a lot more on the plate, companies start feeling the need of a system that offers them better visibility over the disparate components, makes it easier to manage dependencies, and facilitates product reusability at the same time.
Monorepo is used by tech companies worldwide to impart sanity and a sense of organization to all the components they manage. Google, Facebook, and Twitter are also in the list of such enterprises.
However, as it is with most solutions, monorepo isn’t for everyone. Based on the nature of your requirements, you might fare better with a polyrepo or a multi-repository. In this article, we’ll explore monorepo and polyrepo in detail. We’ll go through all their advantages and disadvantages. And then we’ll also present the use cases of both the approaches and end the monorepo vs polyrepo debate for you.
Simform is a leading web app development company. Our pre-vetted developers are adept at modernising architectures and offering a wider range of web app development services, such as frontend web development, progressive web apps, SaaS app development, and more. To bring your upcoming web project live, get in touch with us!
What Is Monorepo?
Monorepo refers to a single repository from which multiple packages are published. These packages remain isolated, and therefore, can be independently upgraded while adhering to all the dependencies.
People often make the mistake of comparing a monrepo with a monolith. But monorepo is a code repository while monoliths are usually massive codebases. Monoliths can be used for monoliths, micro frontends and microservices alike.
Advantages Of Monorepo
Monorepo packs in a ton of advantages for those looking to scale their digital product quickly. Let’s have a quick look at some of them.
Visibility
With everything in a single repository, monorepo brings in a great deal of flexibility to the builds. Teams can have a look at each other’s code and assets and even help in resolving bugs or improve code-quality with cross-team contributions.
Dependency management
One of the biggest challenges for companies working with multiple components is to manage dependencies amongst them. With monorepo, you won’t feel the need of a package manager as it’ll be easier for you to visualize dependencies with all the components available in a single repository. You don’t even need to re-install dependencies for every single instance when you want to update them.
Consistency
Companies often end up delivering starkly different user experiences across their frontend interfaces. It is primarily due to each team going their own way. While design systems are the best way to address the issue, monorepo does its bid to improve consistency and enforce code quality standards with all the codebase in one place.
Easier refactoring
With monorepo, you don’t need to make a pull request for every repo, even for large-scale refactoring. You can update several packages in a single commit with an atomic pull request. Such a feature helps save a lot of time and significantly enhance maintainability over the long run.
Improved reusability
Monorepo enables you to reuse packages while keeping them isolated from other packages at the same time. You can easily consume remote packages via a single entry point using tools like Lerna and Yarn.
Monorepo Use Cases For Frontend
Given the benefits of monorepo, and the need to scale quickly in the current digital landscape, a lot of companies use monorepo for their frontend. Let’s have a look at such examples and understand how organizations are benefiting from this strategy.
Zocdoc leveraged atomic commits for speed
Zocdoc is a leading online platform that books medical appointments and connects patients with doctors worldwide. From their humble beginning as a service to locate dentists in Manhattan to operating in 2,000 cities with over 5 million monthly appointments, their growth has been exceptional.
Although, they had already adopted the microservices architecture to scale and modify their backend seamlessly. A decoupled-microservices backend also meant shared-frontend elements across multiple web applications.
Plus, to ensure that they didn’t need to rewrite the code for these reusable frontend components, they also built a shared Design System library that would contain all these components. So far, they seem to have taken all the right steps, correct? Yes––all except one!
Since frontend components evolve continuously along with the product, they regularly had to upgrade the library components even though not all components required upgrades or changes at once. But as all of them were present within the Design System library, they had to roll out a new version of the library every time they made changes to a component.
This methodology posed all kinds of challenges before them. Do they upgrade other components at the same time as well? Do they not upgrade the rest of the pieces until necessary? How do they manage the piled-up version changes when it’s time to finally upgrade a component?
Their design system’s repo had other drawbacks such as:
- It was difficult to pin-point what changed between the different versions of a component
- The system wasn’t scaling well as the comprehensive testing upon upgrading each component led to a significantly higher time to ship code.
All this friction with making changes opened their eyes––they needed a better framework to manage their reusable frontend components. And Monorepo came to their rescue.
With this monorepo version of the design system, they were able to publish each component atomically. This meant they no longer had to create a new version of the entire library or modify components out of turn.
Easier product development for ABC Life
Going by Zocdoc’s experience, monorepo sounds like a must-have for any enterprise relying on a shared component library for product development. ABC Life is another big player who adopted monorepo in conjunction with a component library.
When they transitioned to an API-based, component-driven frontend architecture, they also used components as the building blocks for their frontend. Smaller components help make more extensive frontend components.
Teams at ABC Life also learned the importance of monorepo while building these frontend components and the freedom it’d give them with product development.
Tim Holt from ABC life stated that, “At its inception, we chose to structure the project as a monorepo, using Lerna for managing the colocated packages. This allowed us to develop our component library as a self contained package, while simultaneously making them available to each application within the monorepo.”
Smoother migration for HMH
HMH is a popular publisher of a variety of work from various genres such as fictional, educational, and non-fictional. Their educational platform, Ed, has millions of users worldwide. To cater to this large a user base, they had to undertake a few scaling projects.
Right from the beginning, it was evident that scaling would be complex with their monolithic frontend setup. So they decided to bypass the issue by choosing a micro frontend framework. It was a great way to have their 8+ teams work simultaneously on the product and improve upon it without affecting each other’s tasks.
When HMH started this migration from frontend monolith to micro frontend, they found it troublesome to work with two repos for Angular and React codebases each. They were also eyeing to gradually move from Angular to React, which further complicated the process.
To remove some friction from the product development lifecycle, HMH used a UI monorepo and clubbed the two heavily independent repositories.
As Cathal Geoghega, the then Sr. Software Engineer at HMH, wrote, “Around the same time that we started to look at how we could migrate our existing apps to S-SPA, HMH decided to move towards a UI monorepo….We felt that the next logical step was to migrate our Angular and React projects into the monorepo and lean heavily on Lerna and Yarn workspaces rather than maintaining two heavily dependent repos and pipelines”.
With the help of monorepo, they were able to streamline much of the development lifecycle and add new features with ease. However, they also admitted that monorepo wasn’t the solution to all their woes, but its pros far outweighed its cons for their use case.
Disadvantages Of Monorepo
So far we discussed all the benefits that monorepo brings along with it. But as we mentioned earlier, it doesn’t fit the bill for all. Here’s where it doesn’t shine bright:
Can’t restrict access
Monorepo doesn’t allow selective sharing. All parts of the repository are visible to everyone at any time. This may lead to security issues in some companies.
Steep learning curve
It usually takes new developers long enough to get used to all the tightly coupled dependencies when they start working with an organization which already has a monorepo in place.
Not suitable for for Git
Large scale projects with monorepo and Git usually don’t go well. The performance takes a massive hit for such projects on Git because of the numerous commits, refs, branches, files tracked and what not.
Polyrepo To The Rescue
Multirepo or polyrepo is the usual state of repositories when you work on various components independently. One clear benefit of such an arrangement is the decoupled nature and version-controlled repository for each project.
Polyrepo is the choice of many if you don’t wish to deal with the demerits of a monorepo. However, you should also note that most of the benefits of a monorepo don’t apply to polyrepo. So, it’s up to you to decide what you prioritize more for your project.
Also, monorepo and multirepo seem to loosely exchange the advantages and disadvantages among them so let’s jump right into a real world example of multirepo execution.
Outbrain’s Switch From Monorepo To Multirepo To Hybrid-repo
Outbrain is a leading web advertising platform that displays those small boxes containing links on webpages. And they had their fair share of experiences when it came to deciding upon the codebase repositories for the product.
They had monorepo in the beginning, and they reaped its advantages to the fullest. They could easily reuse code and refactoring got simple whereas communication became intrinsic among product teams.
But after some time and growth, things started to stagnate, and the product development lifecycle became sluggish. Errors popped up throughout the system, and scaling proved challenging.
It was only when Outbrain adopted multi repos, these issues started to disappear. It allowed the teams to be more agile. Build times got shorter, and it became easier to deploy code for production.
However, this strategy also didn’t serve them well for long. With the increasing number of teams, they started experiencing more dependency conflicts. The documentation wasn’t satisfactory anymore, and there were far too many errors during production.
After a stint with monorepo and multi repo each, Outbrain has adopted the hybrid repo. With this structure, they hope to get rid of challenges posed by the previous two repo strategies. They’ll have one repo for shared libs and API communication while there will be another one for services and utilities.
Here’s how Avi Youkhnanov, Platform Engineer at Outbrain, explains the merits of the hybrid approach:
“What do we expect to get from our hybrid approach?
Easier communication between teams—similar to the way we get with mono-repo, changes will be transparent and easier to coordinate.
Reduce dependency conflicts—since we have one place with a repo that manages those dependencies. Now repositories with services will have to upgrade only one dependency instead of a couple of versions from multiple teams. It means easier version alignment.”
The Wrap-up
The key takeaway here is that you can’t blindly follow any approach. You’ll have to sit down and weigh-in all your options against the goals you have. There might even be times when you’ll have to craft a whole new strategy yourself just like Outbrain did in the above example.
However, making those decisions can be a little easier if you have a competent and seasoned team by your side. Simform has been expertly assisting organisations by being an extended part of their team for more than a decade now. Our developers and executives can help you at every stage of your frontend scaling journey while making the experiences richer for your audience.
Feel free to join us for a virtual coffee date and discuss how Simform can assist you in realizing all your software development goals.
