I'm in the early stages of a web application that will contain a client side JavaScript application that is deployed to the client's browser and a server side REST type API that will reside on my server. The two will communicate using Ajax and JSON data.
Now here's the thing; they are being developed completely separately, not even sharing one line of code or one resource. Both are Node.js applications. The server side uses express and sequelize for all the server side stuff, and the client side is developed using hem development server with stylus and coffee-script and will be compiled down to 3 files (index.html, application.js and application.css) that will ultimately be deployed by the server as static data.
The part I'm uncertain about it how to version control this. Should they have shared or separate version numbers for instance. Also how should the Git repo look. Is it common for a Git repo root folder to contain two or more folders with separate but intimately related projects? Or should I separate them by branches, one called server, one called client? Or should I split them into two separate repositories altogether? (This would be more expensive as I'm using GitHub private repos)
I'm not looking for anybody to tell me what to do, but inform me of the pros and cons of the alternatives. In your experience what would be the best course of action and why.
If the project you are on is a single project with lots of parts it is less important to keep things separate. It might still be easier if each module were separate. But if you have lots of small or medium projects that use various modules then it is very useful to have separate repos.
Yes. You can put multiple projects in one Git repository but they would need to be on different branches within that repo.
If your projects are independent, it's fine to keep them in separate repositories. If they share components, then put them together. Very good reasoning, this should be the top answer in my opinion.
Yes you can, but is not recommended. Best practice is one repo per project always. Otherwise you have multiple projects updating one repo, that can mess with the code a fair bit if not set correctly. If the project is set up to be read-only on one project, that is an exception.
The general rule of thumb is, "things that change at the same time should be versioned together."
If the backend needs to support multiple clients and will change independently of your frontend, as it would if you were going after a services-based architecture, then it's worth thinking about separating these things into separate projects.
However, since it sounds like these two projects will be fairly tightly coupled, and your web application only makes sense with both in place, I'd suggest that you start by keeping them in the same repository. It's a lower-friction development experience, and you can always split them up later if it gets to be painful or if separate teams need to work on them.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With