Git repos for Frontend and Backend parts: one or several?
Most of applications created for commercial use have Backend and Frontend parts in our days. We normally store the source code of these applications in Git. When application becomes mature and large enough we may ask ourselves if code for Frontend and Backend parts should be stored in separate repositories.
In this article I will discuss what effects such choice may have towards team productivity and flow of work. I aim at adding more clarity to myself in how to make such a decision.
Areas of impact
I identified three broad areas of impact: application development process, build and testing process and deployment and release flow. For all of these areas I will discuss considerations one has to make before making the choice of having single or multiple repositories.
Development process
Developers often lack of understanding of how all the parts of an application work if they don’t see those parts while working daily. Single repository may be an advantage here, because it may give developers at least a rudimentary understanding about the whole application.
It maybe difficult to structure the code of all application in a single repository. Different technology stacks may require different way of structuring the code. Single project structure may be suboptimal compared to a structure which is optimized specifically for the Frontend or the Backend parts. In such case two repositories may be easier and more clean solution.
If Frontend and Backend parts are built by different developers then separate repositories give them flexibility to define their own development processes independently. On other hand, if same developers work on both parts, then separate repositories may create a cognitive overhead if development processes are different for both parts.
Building and testing
Developers need to build and test their applications very often, sometimes multiple times a day. Building and testing only Frontend and Backend part is usually faster. Building separate parts independently should be easier if those parts are in the separate repositories.
End-to-end testing requires both Frontend and Backend to be deployed together and then tested as a whole. If all the parts are in the same project, then it is easier to configure building process and test runs as one continuous process.
Deploying and releasing
If Frontend and Backend are developed separately, then there is a need to keep track the version dependencies. This can make deployment process more complicated compared to having all the code in a single repository.
In case of production problems, rollbacks from a single repository should be easier as it would require just a single commit hash. In case of two repositories developers should decide to which versions of Frontend and Backend parts rollback should be done.
Conclusion
There is no single answer if separating Frontend and Backend to several repositories is good or bad practice. It depends on the team structure as well as how the application built, tested and deployed. Therefore before making the choice I suggest to think how important are the points described above to the particular context and how such choice will affect the flow of value.
Enjoyed this post and interested in software development? You might like my latest article How Organizations Can Add New Tech and Avoid Developer Burnout.
