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
Best Answer
A simple solution to this is packaging major versions as a single compatible product (at least for the core functionality), with minor versions implementing additional non-core features, which may or may not work in all frontend-backend combinations.
For this, you'll want your semantic versioning on the API between the frontend and backend. Update major version number on both when there's little backward-compatibility. Use the minor revision number for features and optionally, frontend features that simply require small API additions to the backend - but then state that the feature requires a newer version of the backend.
Then you could say something along the lines: "All our products support vX.y frontends working with all vX.z backends and can read/import from v(X-1).z and v(X-2).z backends"; "small feature X in v8.11 frontend requires a backend newer v8.3", etc.