2

I have a rather simple application which consists of an angular frontend and a REST API done in C# For the frontend I use WebStorm and for the backend Visual Studio. Now we need to introduce a new version control and it has been decided to use Team Services (Git).

There is no code or any assets shared between the frontend and the backend, but they are logically coupled because the frontend needs the backend and the backend is only (and will only ever be) used by this particular frontend.

I'm fairly new to Git but I know (a bit) what submodules, subtree etc. are.

My initial thought was: Clearly, two repositories are the way to go, since I can publish frontend/backend separatly on different servers, as long as the backend exists somewhere the frontend has access too everybody will be happy. And:

  • Webstorm and Visual Studio won't interfere with each other and "steal" commits (which I personally find annoying).
  • Or show files which don't belong to the project. For example I would see every backend file when opening my frontend in webstorm since they are in the same repository. Or am I wrong?

On the other hand I would have to make sure myself that Frontend and Backend are always compatible. Which I think isn't that hard. But those two repositories would be totally separated in git and there wouldn't be any connection whatsoever between the two.

As far as I know it is not possible to tell git or webstorm/visual studio to just use a specific subdirectory, right?

So, my question would be. What would you recommend in this case?

  • two repositories
  • one repository with just subdirectories
  • one repository with subtrees (and an empty parent repository?)
  • something different

Thanks in advance

Arikael
  • 131
  • 4

1 Answers1

3

The biggest issue I think about for projects like this is, 'How can I keep the front-end and API in-sync with each other?' You don't want your front-end asking for things that don't exist or have been deprecated by your API.

The easiest way to solve this issue is to have one repo, where changes in the API and front-end are all in the same commits / PRs.

This falls apart in a lot of places though. It can be harder if you want to swap out your API or front-end later. Also, you can end up wasting a lot of time when doing deployment if you have a long build step, or a large test suite.

There's another post that goes over a lot of pros and cons, but I think this really boils down to team size and how you plan on doing deployments. If it's a small team, even up to 4 people, you're probably good with one repo. If you have a large team, and a dedicated versions, and so on, managing one repo can get out of hand.

Again, I would recommend looking at the other post as the question and the answer provide a lot of good considerations.

When to separate a project in multiple subprojects

JRJurman
  • 347