Keep the number of repositories as small as possible.
You can easily start with just one repository and move some code to another when needed. This is to make your life within the project as easy as possible.
As most increments require changes both in the API and the UI, it makes sense to treat them as one
Put all subprojects of the same system (e.g. a web app) to the same repository:
my-project/
ui/
api/
I tend to use Yarn workspaces when working a project like this. In most cases, you can go without. It is only when you have co-dependent subprojects that share the same dependencies as React.
Pros of having all subprojects in one repository
- Much nicer to navigate the project and make changes
- Easy to come up with descriptive commit messages. "Add a logout feature" vs backend: "Add an endpoint for removing user's session" + frontend: "Add a logout button"
- You see all changes you've made with
git status - You can run tests for all projects at once
- No risk of deploying non-matching / incompatible versions of the project
Cons of having all projects in one repository
- Some tools are not made with monorepos in mind. Especially all tools that build your project (CI tools, static site hosts) sometimes make assumptions of where your "
public" directory is. Most of these can be configured these days tho. - If you are building a multipurpose standalone API meant to be used in many projects (that cannot be in the same monorepo), this might not be the best approach. I'd suggest you use a monorepo if the subprojects are clearly linked and depend on each other.
Cons of using 2 separate repositories:
- You need to create 2 separate commits for each increment
- Changes are reviewed in two separate PRs
- 2 repositories can easily get out of sync when one PR is accepted before the other one is ready
- "Why isn't this feature working? 🤔" "Ah, I forgot to pull in the latest changes from the backend repo"