Ask HN: Startups – Are you on a monorepo or multi-repo set up?
Hello friends! We're designing our next iteration of deployment tooling, and wanted to get a feel for whether startups with < 10 engineers structure their code in a monorepo or multi-repo way. (no judgement either way).
Do you -
1. Mono-repo (frontend + backends + services + infra [...]) all in 1 repo)
2. Multi-repo (separate out frontend, from backend / each services /) or any other cross-repo structure
What's your guys' structure? Monorepo, no question. Has had only upside as far as I've experienced. 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 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. 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. 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. 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. Monorepo for client and services - enough code sharing that it would be pretty weird to separate them out. Mono-repos forever and always, lessons learned in the last 20 years ;) Currently running this in a single repo: https://github.com/openkoda/openkoda We were on a mono-repo and we're moving to multi-repo with the goal of increasing release frequency. Why is a monorepo blocking you from increasing release frequency? Are you releasing all components together or something? Monorepo, it has made sharing code and tools a lot easier. Monorepo with pants for builds, 4 Engineers.