We develop a web app which consists of a frontend and a backend project. The frontend is consuming an API that is provided by the backend. Frontend and backend are developed separately by different teams but in the end, we deliver one application to our customer. Both applications getting build separately by gitlab-ci and deployed independent from each other to the dev/test/staging system. They are then running in different docker containers connected to each other.
If we simple stick to the git flow for both projects we would finally have a tested combination of frontend and backend on our testing environment. For a simple one-sided application I would suggest this state gets simply tagged and released. Then you would have something like v1.0 which can be delivered to the customer by deploying this on the prod system.
But if we look in the particular FE/BE project, there are very likely different versions. For example:
Frontend: 3.14.324 Backend 2.1.92
My question here is, does it make sense to think about what versioning strategy to apply for each single project to avoid incompatible states between these two applications? Or just say "this combinations works"? Is there a need to have a convention how these version have to fit to each other? How to manage that dependency between those two sides?
What is the usual way to handle different apps working together especially if there are two different teams working on this projects separately?
So one scenario i know is that we change something on the backend so that the frontend will get an error. The typical "does not work anymore but still worked 5 min ago" scenario which will cause so much headache to our devs. How can we avoid that but still have a working product in the end?
Some opinions from experienced developers might be helpful here too.
Thanks a lot