from Hacker News

Ask HN: Startups – Are you on a monorepo or multi-repo set up?

by ashiban on 5/13/24, 6:59 PM with 12 comments

• by seattle_spring on 5/14/24, 9:37 PM

  Monorepo, no question. Has had only upside as far as I've experienced.

• by noop_joe on 5/14/24, 3:27 PM

  We are building an application/infra platform, Noop [0], it's multi-repo, one key benefit is it facilitates the deployment of different system components with greater isolation.

  That said, I'm a big fan of mono-repo. Noop actually supports developing mono-repos in a really interesting way. Here's an example [1] Vue + Node backend in one app. It should be pretty straightforward to see how you might be able to extrapolate that to more services when needed by looking at the .noop/blueprint.yaml in the linked repo.

  0. https://noop.dev 1. https://github.com/noop-inc/template-nodejs-vue

• by whodev on 5/16/24, 6:35 PM

  Guess it depends on your definition of a mono-repo vs multi-repo. I'd consider what we have as a mono.

  We have one repo which is our main web application (user dashboard, landing page, etc..), our API, and our scheduled tasks. With how much code is shared between these services it just makes sense to keep them together.

  We then have separate repo's for other services that aren't critical or apart of what was mentioned above.

• by FlyingAvatar on 5/15/24, 1:35 PM

  Not at a startup, but at a small company (<10 developers) we regretted not doing a mono-repo.

  We had our own GitLab instance and we were all open source enthusiasts and building micro-ish services, so it seemed natural for us to do multi-repo.

  Eventually we realized it was creating a lot of unnecessary overhead, as we often were submitting patches for a single ticket to multiple repos which all required separate reviews.

• by moomoo11 on 5/14/24, 1:18 AM

  I have 4 repos.

  All the backend work is in one repo. The monolith has everything including the core API services, background/batch processing, etc.

  I have a mobile repo but we aren't ready at all yet to work on mobile. It is a flutter app, but mostly proof of concept type stuff.

  Then there's 2 repos for web UI. One is a next js app for generating applications for customers, and the other is a standard react SPA which is what customers use to build their applications.

• by theolivenbaum on 5/15/24, 5:17 AM

  Mono-repo, mono-language, and really enjoying it - enables much easier refactoring and using a single strongly typed language makes lots of issues go away. We do have a few other repos for open source projects or libraries we publish, but the majority of the work is done on our mono-repo.

• by aranchelk on 5/13/24, 7:56 PM

  Monorepo for client and services - enough code sharing that it would be pretty weird to separate them out.

• by mgl on 5/15/24, 4:11 PM

  Mono-repos forever and always, lessons learned in the last 20 years ;)

  Currently running this in a single repo: https://github.com/openkoda/openkoda

• by fullstick on 5/13/24, 9:51 PM

  We were on a mono-repo and we're moving to multi-repo with the goal of increasing release frequency.

• by lbhdc on 5/14/24, 2:07 PM

  Monorepo, it has made sharing code and tools a lot easier.

• by Eridrus on 5/13/24, 7:25 PM

  Monorepo with pants for builds, 4 Engineers.