8

So I am going to use ReactJS for the front-end for a web application

The application is mostly CRUD stuff but with some ajax UI etc.

For the back-end I am using Laravel

Right now I have both the front-end code and the back-end code in the same repository which works for me so far, but I get the feeling that I have two separate projects in the repo. Both can/have a lot of dependencies etc.

The structure looks like this

project/
  client/ 
    Front-end code...
  node_modules/
  server/
    vendor/
    Laravel...
  package.json  
  webpack.config.js
  webpack.config.production.js
  etc.

What would you do?

Thomas Andersen
  • 221
  • 1
  • 4
  • 1
    Possibly relevant (though it's not the common use scenario, unless you're Google): Google uses a single repository for all its projects! [And they have a justification why](http://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext). – Andres F. Oct 24 '16 at 19:08
  • 1
    Possible duplicate of [When to separate a project in multiple subprojects](https://softwareengineering.stackexchange.com/questions/194822/when-to-separate-a-project-in-multiple-subprojects) – amon Oct 22 '17 at 10:33

1 Answers1

12

This depends. You can ask yourself a couple of questions to reach an answer:

  • Do I often want to re-deploy one half without the other?
    Do most changes affect either the frontend or the backend, but not both?

    If the development for the front- and backend is largely separate, it can be easier to keep them in different repos.

    In contrast: If development & deployment is coupled, the front- and backend together form a single software.

  • Do the frontend and backend communicate through a stable, specified, versioned, and backwards-compatible API?

    When the backend and frontend are developed separately, they still have to communicate with each other. The backend is now like a library used by the frontend. Whenever you re-deploy the backend, you upgrade that library. How can you make sure everything will work? Well, aside from testing each new frontend version + backend version together? The API may only be changed in a backwards-compatible manner. Such changes include adding new URLs, but prevent renaming or removing URLs. If you have to do an incompatible change, the frontend must be updated before it may be used together with that backend version. To check for that, you need to version your backend releases/deployments. Your version control revision number is not suitable as a version number.

    If thinking about releases and backwards compatibility and versioning seems over-engineered for your application, then do not separate them. Keeping them in one repo and always testing them together makes it much easier to keep the whole code base consistent, and to iterate quickly.

For nearly all applications, it makes sense to keep them in one repo. This is just so much simpler. In practice, a stronger separation becomes desirable when you want to reuse the frontend or backend across different projects (e.g. when the same backend serves a single-page web application and some mobile apps), or when the frontend or backend are developed by separate teams – using a common repo would then become annoying and confusing.

amon
  • 132,749
  • 27
  • 279
  • 375