Developers February 18, 2020

Multi vs mono repo - Pros & Cons?


Hi Indie Hackers!

After working in my side projects for a few months I found myself with 8 GIT repositories for different parts of the project (website, API, jobs, lambda functions, a bot...) so yesteday I decided to put them all together inside a single mono repo.

I think this is going to make my life a lot easier and, as a solo dev, I dont think I'm going to run into conflict issues or things like that. To be honest, I'm not sure if this is going to be the right move long term so I just wanted to check with the rest of the community

  • How do you manage the code of your projects (mono/multi repo)?
  • Do you know of any pros or cons of each?

See ya!

  1. 3

    Monolith has always served me extremely well, even when deploying microservices (nothing a shell script can't handle)

    I'm currently working on a multiple repo stack at work and while I can see the appeal, because we have shared code, it tends to be fragile in terms of linking of repositories and what not.

    Not having done it, I suspect that working with separate repositories that have absolutely no shared code would be pretty nice, but I still think mono wins out just in terms of being able to spin up docker from your repo, instead of having to have another repo that coordinates all of your other repos and such.

    1. 2

      "it tends to be fragile in terms of linking of repositories"

      From an engineering manager's perspective. Repo size vs the number of repos is directly related to team size. For smaller teams, 100% do monorepos.

      When you start to have autonomy between teams repo splits become important. Of course, if something is public split repo.

      1. 1

        we're a bit upside down in that regard, swung a bit too far into the many-repo direction :P

        1. 1

          I've definitely been there. The context switching and complexity introduced when developing simple features can cripple the feedback loop. I hope your development tooling is amazing :)

          1. 2

            Could be better, we're slowly working towards consolidating repos at this point. Getting better every day :P

            1. 1

              One item I would recommend from an architectural perspective is looking into DDD (Domain-Driven-Designs) Shared Kernel. There are a few more integration strategies but DDD outlines the tradeoffs pretty elegantly. There's a good book like 150 pages on foundations of DDD called Domain-Driven Design Distilled

            2. 1

              Good call :) better for a growing team.

  2. 2

    I have one public monorepo for Saasify and one private monorepo for proprietary stuff.

    Both use yarn workspaces + lerna. Feel free to use my linked repo as a template if you want. 💪

    It's a huge timesaver as most of my PRs involve touching a lot of different logical services and packages.

    1. 2

      Great, I'll have a look. I've never used yarn workspaces so I'm sure it will help.

      Thanks for sharing it 👏

      1. 2

        Yarn workspaces and lerna.

    2. 1

      I haven't figured out how to use lerna yet (looks like it's for shared libraries?) but yarn workspaces rock!

      Because I haven't learned how to do shared libraries, I end up copying the same file across some of my workspaces, which I absolutely hate, but it works right now as the code sharing across the projects is pretty small so far. Embarrassed to even type that last sentence out LOL

      1. 2

        yeah, whatever works for you is the way to go 😄

        if you're interested, a lot of projects break up re-usable logic into npm packages that lerna helps to manage. my public monorepo linked to above is a solid example of this approach (there are lots of others like babel, jest, zeit, etc).

        happy to answer any questions if you have them - but at the same time, if this seems like overkill or if it'll distract you from being productive with your current setup, then KISS 💯

        1. 1

          🙏 Ahhhh, gotcha, that actually clarifies my mental model up a bit!

          But there's still one question I've got. Do the re-usable packages become public on npm, or is it possible to have them just scoped to my monorepo?

          1. 2

            You have a few options.

            1. All packages are public and published to npm.
            2. Some packages are marked "private": true in their package.json and they won't ever be published.
            3. Publish some or all of your packages to a private npm organization. This is just like normal publishing except that only people you permit to see & use your package can use it like @ myorganization/mypackage.
            4. Some combination of the above 😄
            1. 1

              💪 Amazing. Appreciate it!

  3. 1

    I would go for mono repository as well. Easier to manage. That would only work well for solo developer.

  4. 1

    I've tried nx workspace recently (I'm full-stack JavaScript) for a play project - and I loved it so much that I'm going to introduce it at my corporatey $DAY_JOB. It has a lot of things built-in - managing library versions for the entire project, managing unified code styles, but also life-saving dependency management between my libs and apps - e.g. you can have a "ui" library that's not allowed to import anything (other then from node_modules), and on the other side, you can have a "feature" library, which can import "ui" but not other features. A lot of interesting things like that.

    The cons of monorepos I can't really say, as I haven't used it long enough. I would say that it takes a bit of time to adjust to the workflows that the nx expects, but they're all sane and reasonable so far.

  5. 1

    monorepos are perfectly fine for what you're saying I think. Even from a DevOps perspective you can trigger builds only when anything under a specific folder is changed. If they're related to the same project then I don't see a problem with that

  6. 1

    My rule of thumb is this.

    Are those things different applications? For example do you have a backend API and an SPA frontend that is just one of many clients (theoretically). They they should be developed and versioned separately. This is especially true for teams.

    As a solo person though anything that is easy to work with (more comfortable and faster) for YOU.

    As for myself, I would do full-stack monoliths.

  7. 1

    Done both and prefer monorepos all the way! Gave a talk at a local meet up about pros and cons of you'd like to check it out.

    1. 1

      Thanks for sharing the slides,. I see you've detailed how to manage them with yarm workspaces so that's going to be super helpful for me!

  8. 1

    We used to do multi-repo when working on CurveFever, but it was very messy because everything was interconnected so whenever we created a new feature we had to create a branch on all those repos. We did create some helpers using GulpJS to switch all repos to a specific branch or to create new features, but overall I think monorepo would have been the better choice. Maybe could still keep client and server separated somehow, but having shared code between them (same game logic on client and server), would still add a strong connection between the two.

    I think multi-repo only works well if all the components can be changed independently, that means all services should have backwards compatibility (eg. you revert changes for one service, you shouldn't be forced to revert the changes for all others) and there should also be no strong connection between the two repos (which is hard to do as they usually communicate in some way, and if this communication language does ever change, the change has to happen in both repos).

  9. 1

    I'm not sure if this is going to be the right move long term

    Worrying about this now is definitely not the right move. This decision is easily reversible, so there's no need to spend time thinking about hypothetical problems that might occur far in the future.

  10. 1

    So my App is build in a monorepo, (yarn workspaces & lerna)

    The good part:

    • I can publish private packages e.g. [@brabble](/brabble)/controllers
    • I have matching versions for web and native (I am using React)
    • In general code sharing becomes easy

    The bad part:

    • You don't get a lock file for each package, this is bad because I still deploy everything separate in docker/k8
    • React native is annoying because you need to hoist everything... (loosing the benefit of a monorepo)

    I am still not sure but most likely soon I will separate it. It was fun to learn and sure works fine once it is setup (it takes some time).

    1. 1

      This is similar to the set up I choose. A monorepo for MVPs allows you to work so much faster.

  11. 1

    Took our biggest projects from multi to mono and have been so happy with the move.

    But none of these have outside parties needing access and updating single projects, in those cases multi may make sense.

  12. 1

    I'm definitely on team multi-repo. As a small business owner, I work with a lot of contractors. There is no reason for my marketing contractors to have access to our API layer. Also all of the automated deployment. I guess you probably could get your pipeline to pick out an individual project from a repo, but it just seems simpler to connect each repo to it's own pipeline.

    1. 1

      yeah, in that case, multi repo makes more sense.
      I've started working in a CD job and yeah, looks like I'll be able to make it work and deploy just the services affected thanks to DockerHub webhooks :)

  13. 1

    I'm using multiple repositories as you did before (website, APIs, jobs, ...). I like it this way because it helps me to keep my projects clean as it forces me to look at things at a more modular way.
    And in terms of CI/CD, having multiple repositories makes it easier to restart just the relevant services that have actually changed.

    1. 1

      I'm currently doing all my deployments manually but I was planning to automate them and it's true that with a mono repo it's going to be more difficult to deploy just the parts that have changed... 🤔 I'll try to find a way to do it

      1. 1

        Can only recommend to do so! Once I had them set up, automatic deploys have been a huge time saver for me.

        1. 1

          Yeah, we use fully automated deployments in my 9to5 job and it's a life saver. Not to mention all the human errors it avoids.
          I just have to find the time to do it.