Intro
Hello fellow developers!
If you're like me, you may have spent some time working with microservices and have grown accustomed to the flexibility and independence they offer. However, as your project grows and evolves, you may find yourself feeling the pain of managing multiple codebases and the overhead of coordinating changes across teams.
That's where monorepos come in. A monorepo is a single version control repository that contains multiple projects, each with its own set of dependencies. This allows for better collaboration and easier code management, as everything is in one place.
Why use it?
Normally (in javascript ecosystem), monorepos should be easy to maintain, setup, and deploy! Imagine doing a fix for multiple services in a polyrepo microservice, or even doing feature on the API and in the app. You have to clone and install the dependencies of each service, test, and deploy each per repo. Seems a lot of work, right? But with monorepo, you can easily do this in one repository, and apply the changes in one go! That's the beauty of monorepo.
Why not use it?
You don't have the time to do it.
Kidding aside, there really are some troubles on setting up a monorepo especially if you're not in the javascript ecosystem.
Language Oriented - While there might be language specific support for setting it up, it still might require a lot of work! Also, if you have a multi-language microservice setup, it would take time to perfectly nail it!
Inconsistency - For larger teams, it might be difficult to maintain numerous file changes in the same/different file, which may lead in breaking the app. This, however can be solve to which teams should own the service or app.
Machine dilemmas - Since it has lots of services inside the project, IDEs might hang when installing dependencies, and running multiple services concurrently. This might also be an issue on CI/CDs as base runners might not be able to accommodate large amount of packages cached/uploaded artifacts which might make extra costs on you.
What should I consider when setting it up?
Within the JavaScript ecosystem, several utilities already exist to support the establishment of a monorepo architecture. Npm, Pnpm, and Yarn are among the prominent tools utilized for this purpose. These tools offer valuable features and functionalities that facilitate the management and organization of monorepo projects, streamlining development workflows and improving code sharing across multiple packages.
There is only one thing you need in order to setup your Node JS monorepo, and that is Node itself. Upon installing node you can choose whatever tools you want on how you want to configure your project from scratch, or you may also want to consider using build systems such as Turborepo or Nx for quick and easier setup.
TLDR;
While there are lots of problems solved by monorepo, it also has downsides. Scaling it might cost you a bit or more, but might save you time.
For reference you can take a look on my old repo which uses yarn workspaces. You can fork, clone, and play with it locally. Happy coding!
If you have any implementation or articles that discusses monorepo setup in other languages aside from javascript, or any appreciation/detestation with monorepos, please leave a comment! I would love to see some discussions about it! π
Top comments (2)
Setting it is a comparatively easy task. Maintaining is what the whole complexity and struggles are about, especially for bigger codebases. Each tooling / dependency update may turn into nightmare, the fancier your setup is.
The biggest pro for monorepos is, that you can do one change, on one module/package, and it is directly available in the others - at least for JavaScrip/Typescript.
There is no need to build a version, push it to npm, update the deps in the other repo, only to see that you missed something and do it all over again.
Youβre real quick here, if you work alone or in a very small team.
Also keeping the deps and versions consistent might be easier.
But on larger or multiple teams, where you also might want to deploy separately and work independently, monorepos can become quite challenging.
In these cases you will need defined processes, defined responsibilities and some other overhead to get it work.