5

Let's suppose I have a backend with API-only Rails. There is also a Javascript single-page application (Aurelia, but could be something else) talking to this API.

Should I keep these together, in the same Git repository, integrating Rails with Aurelia to some extent, maybe with the Rails asset pipeline building/bundling Aurelia somehow? Can this even be done with reasonable effort? Or should I keep them totally separate, because in reality they are two separate things?

What are the pros/cons of having the Aurelia project set up inside the Rails project or totally separate?

Also I suspect this will be different during development and in production. In prod, the Aurelia app will be about two .js files anyway, which will be served by the web server as usual. I think it's better to use Aurelia tooling separately to build this.

How should this be done properly?

3

The technical benefits of multi-repo are fairly minor: smaller repositories, faster clone times, possibly improved performance on CI, but nothing that should make a real impact on anthropic scales. There may be organizational advantages depending on how communication and process happens between your application's team members.

The technical downside of a multi-repo will be noticed immediately: you can't modify files across two repositories with a single commit, can't merge changes across two files in different repositories in a single commit, can't revert changes across two files in a single commit, etc.

If your client and server are tightly coupled, not being able to make changes on both sides in lockstep will require you to waste a great deal of effort in order to perform day-to-day development tasks. Shipping a new feature? Have fun creating two feature branches, doing two staging deployments, doing two pull requests, doing two code reviews, doing two ... ad infinitum.

To avoid having them be coupled might be even worse: you will need the client to be able to support multiple versions of the server and for the server to support multiple versions of the client - hiding menu items that require features detected as missing on the server, supporting or otherwise handling obsolete messages and parameters from old clients. You will need to be able to QA new features on either side independently from making the same changes on the other repository, this includes both automated testing (what could have been one suite of integration tests are now three: client integration tests, server integration tests, and end-to-end tests) as well as User Acceptance testing (can your stakeholders consume a REST API and conclude if it meets their needs? If not, prepare to build things over several times. Can your UI simulate a new feature without the server supporting it? Have fun writing lots of stubs.). Depending on your application this could be simple, a great deal of work, or effectively impossible, so you should be quite confident that the organizational benefits of having separate repositories outweighs that cost.

If you want the server to be the server, and the client to be the client, to be able to conform to the conventions of each component's framework of choice without compromises, to have a clean boundary between the products in your project (a demarcation line consisting entirely of the API) you get all of that with a couple subdirectories and a couple 'cd' commands in your CI script, and don't give up being able to change things like the name of a resource or parameter on both sides with one commit, one review, one deploy, etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.