Question 364221 in Reactjs Question posted in
The new location for the React Documentation can be found here.

Reactjs – How to store frontend and backend in git?

Our team has a small web application project. We don’t understand how the backend and frontend should be stored in git.

There are several ideas: store both frontend and backend in different repositories, store both in the same repository but in different branches, or store them in different directories.

Which of these methods is better or more often used in practice?

Tags:

3

Answers


  1. 0

    I’d say storing them in two different repositories would be better. If it were a desktop application written in electron for example, then maybe using two folders would be more efficient, but in your case I’d definitely go for two repos. Plus, it will be easier maintaining the codebase without conflicts with completely unrelated code.
    As for the usage of branches, I’d suggest this small article to understand their purpose.

    Good luck.

    Login or Signup to reply.
  2. 0

    Same repo and 2 different branches bring no added value.

    So it is either:

    • 2 different repositories
    • or 1 repo and back and front code on the same branch called ‘monorepo’ strategy.

    Monorepo strategy could make easier management of technical dependencies between front and back especially if that’s the same team that manages both. You could also have one pull request for back and front feature update so review and testing is easier.

    But it will have an impact on your deployment/packaging process : you need to investigate if having everything in the same branch will make deployment easier (deploy everything on the same time) or more difficult if you need to build 2 packages and handle quality testing of both.

    Login or Signup to reply.
  3. 0

    Definitely don’t put them in branches. Branches are for working on the same content simultaneously, not for storing completely different content.

    With that out of the way, it depends if you want to run this as one project, or two.

    One repo

    A single repo is simpler. You don’t have to coordinate changes and releases between the front and back end. If you have a bug or a feature, it can be coded and tested and released in one project.

    The downsides are that the front and back end will tend to tangle themselves together if you’re not careful.

    Two repos

    This is more complex. It requires that changes and releases be split between distinct front and back end repos and coordinated. For example, if you want to add a feature that touches both ends you need two issues in two projects changing two repositories and then released in coordination.

    The back end will, effectively, be a dependency of the front end. It will need a clearly defined API for the front end to use. This can be good as it will keep the back and front end implementations separated, but it has costs.

    Which to use?

    If you’re very familiar with coordinating multiple dependent projects, and you don’t have a solid reason to keep the back and front ends separated, do the simple thing and use one repo.

    You can always split it later, however it will be harder to untangle.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search