Recently, a client of ours asked us why our developers split front-end (client) and back-end (API) code into two repositories. They had found themselves needing to coordinate work in the two separated codebases to get features done. While creating separate codebases can result in a bit more work when referencing pull requests, documenting work in user stories, and deploying new features, there are several benefits to keeping them separate. Aside from cleaner more consistent code, this functionality allows our developers to write code with more depth and reach. In this blog post, we’ll highlight six reasons for splitting client and API code into two repositories.
When you split code into multiple repos you can scale them independently. For example, you could throw client code on a CDN while spinning up a lot of AWS servers for the backend. This greater flexibility in scaling can save money on hosting and hardware costs and improves your ability to modify your setup as your user base grows.
2. Don’t fix what isn’t broken
It’s better for developing a new back- or front-end without disrupting what’s already in place. There’s no reason to tinker with code that is already functioning. Don’t make more work for yourself!
3. When you’re working with separate platforms
Say you’re working with server and client-side frameworks. Keeping them separate encourages your developers to work synchronously on the front-end and back-end components of a feature. This means your features can be completed more quickly!
4. Separate deployable instances
Our client asked us why you wouldn’t just divide the repo into an API folder and a client folder. We don’t divide the code into two folders because two separate repos allow us to make isolated deployments of the different code.
Also, it’s nice to have the code separated so it stays cleaner and is easier to work with in the long-run.
5. Divide work on a per framework basis
If multiple people are working on the separate repos it’s a nice way to have one person working on the API while another is working on the client, that is if they’ve agreed on the JSON output.
6. Release planning
With two separate repos you can get your team to agree on the individual work they’re going to do, while releasing it all at the same time. This is something that should be tuned to fit the organization though. By partitioning the code in anticipation for release planning developers can do most of their work without worrying that they’ll mess up someone else’s current project and as a team you can keep things cohesive enough so that developers aren’t spending all of their time in meetings trying to coordinate.
I hope you’ve found this information helpful for your own programming process. Feel free to drop a line below if you’ve learned about other effective means of organizing code!