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?
1–10 of 13 posts
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?
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.
We were on a mono-repo and we're moving to multi-repo with the goal of increasing release frequency.
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