Hello folks! What are your experiences with git submodule in the context of frontend/ backend development? Would you like frontend and backend to be submodules inside a main project repository, where project's version can be controlled by checking out suitable submodule commits from frontend and backend respectively? In our case, we have React and Django based frontend and backend with separate development teams respectively. They are mostly independent as they communicate only via APIs. However, currently they are part of a single project repository. The problems I face with the current system is as follows: • Mixing up of frontend and backend commits even though they are unrelated, which makes it difficult to track history. • Ideally frontend and backend should support independent testing, but it is not followed most of the times. So pull requests for backend and frontend depend on each other so that they can be tested manually. Example, backend PR won't be accepted until PR for its frontend is ready. This slows down development for both teams. I think these issues can easily be addressed using git submodules. But it is often said that they are not good practice. What are your opinions?

I would recommend 2 seperate repositories unless theres a reason to have both at one place. Monorepos are also getting popular these days, you can try that.

+1 I see no benefit of having the frontend and backend in the same place especially since as you mentioned, they are two Apps connected via some APIs. Repos come free. If your code is modular right now, might as well copy-pasta one of the apps into a different repo. Don't complicate developer productivity by introducing a new level of version control.

What are the advantages you expect of submodules? I would advise against, because it isn't the right tool here.

Don't complicate developer productivity by introducing a new level of version control.

💯 this

I also agree to have separate repo for Fe and be. What I mean by using submodules is that the main Project repository will have two git repositories in it, which is nothing but submodules. Frontend and backend teams can push commits to these submodule repositories independently. And project manger can release new versions using the main Project repo by checking out appropriate submodules commits. Is this a good pattern?

Why try to create a single repo when its only contents are two independent repos?

Is there ci (and cd) in place? If not, get that done. Once in place, you can tag your repos at end of a build and/or create a release and people can simply check out that release and use it for local dev. As additional maturity, publish a container for every build / tag / release and use that container in docker compose or otherwise for local testing. Introducing a separate repo with submodules just for this sounds like a lot of pain on top of a tool (submodules) that is already a pain

Submodules are useful only for tightly coupled applications and individual modules may be different components of the system deployed together as a single unit