Files organisation

Most SaaS projects are made of 2 layers; frontend and backend. In our case, React and Node. There are 2 common ways to organise our project:

Divide and rule: One repository for each layer

The Node and React app will live in separated repositories. You will have to checkout, pull, commit and push accordingly.

This setup makes sense for big teams. Each team has specialised skills and is dealing with a specific part of the project.

For smaller teams though, it just slows things down. When you're building your product, most of the time, the frontend relies on a change from the backend. The frontend needs to wait for this backend change to be approved, merged and deployed.

One repo to rule them all: Mono repository

Mono repositories work well in this scenario because everything needs to be built. There is no clear line between frontend and backend work. We are focused on features, not the code. Backend or frontend? It doesn't matter. It all has to be done.

When working on a feature, you build whatever is required to ship this feature. Most of the time, it will look something like:

• Create an endpoint to interact with the database

• Build a new UI form to display and manipulate the data

• Write tests

It is easier if everything is in the same place. When the feature is ready, create a pull request. Once merged and deployed, move on to the next feature.

Later, when the team or the app gets bigger, you can always move parts to another repo.

Structure

In our example, we will use a single repository with separate folders for the frontend and backend, named web and api respectively.

Later, the project could have a React Native app in mobile or a queue system in workers.

├── README.md
├── node_modules
├── package.json
├── packages
│   ├── api
│   │    ├── node_modules
│   │    └── package.json
│   └── web
│   │    ├── node_modules
│   │    └── package.json
├── tslint.json
├── tslint.production.json
└── yarn.lock