Front-end supporting multiple back-end versions - Maintaining backward compatibility

Question

I know it's a broad question so I'll try to be as specific as possible. This question is probably as much an "organisational" question as a technical one.

Our company is selling our software/platform to let's say 10 customers (also companies). These customers are all running their own installation of our platform, and let's say all these customers are currently running version 1 of our platform.

Now we are creating version 2 of our backend, to include new features and possibly changing some existing data models. In short, this will introduce breaking changes for front-end version 1.

However, not all our customers will purchase backend version 2, but should still receive new (minor) font-end features. It could be that some of these new front-end features will rely on backend version 2 for the customers who DO purchase backend version 2, but for the other customers we would make them rely on existing endpoints in backend version 1.

Now the big question is: what would be the best way to handle this in the front-end. One could suggest to make a front-end version 2, that relies on on back-end version 2. But as said before, sometimes new front-end features would have to be developed that need to work on both version 2 of the backend, as well as version 1 for the customers that will not purchase version 2 of the backend.

-- The big downside here would be that we would need to create every new feature in the front-end twice (once in version 1, and once in version 2 of the front-end).

Another approach could be to keep one version of the front-end, and have a new feature rely on either backend version 1 or 2, based on a setting/variable that indicates if the customer has backend version 2 or not.

-- Of coarse the big downside here would be that the for every feature, a lot of if-else statements would need to be implemented ( if(hasVersion2){ use version 2 of backend }..else{ use version 1 of backend } ) .

Now I am looking for some input / feedback / experience on how this could be handled most effectively. Maybe you guys have some relevant experience.

TL;DR; How do you handle new front-end features & improvements that need to work both with a new version of a backend, as well as a legacy version of a backend?

Answer 1

Options:

1) The users can upgrade or hang. The Version 1.X is going out of support on the Xth of the Yth.

2) Support both lines going forward. I cannot recall the product at the moment though my memory is twigging a post by Joel somewhere. There is a company that designed a solution to a problem 3 times. They built V1, learned rebuilt it as V2, then when technology changed again rebuilt it again as V3. V1, V2, and V3 are separate software products that are separately, but all actively maintained.

3) Avoid introducing breaking changes. Provide the V1 and V2 interfaces on your backend. If that means adapting an internal super-model into the V1/V2 spec fine. If that means emulating/simulating the V1 semantics, provide it. If that means writing a plugin that provides the dropped behaviour, write it. The customer can receive updates, and upgrades without flipping their client. If a new Feature can work with just V1, it can be worked into both clients, otherwise its a V2 only feature.

4) Don't write a V2. Just improve the V1. If you would like to provide an alternate client go ahead. Otherwise you can have a single client that provides features based on the reported capabilities of the backend. This also gives you a nice platform for providing server-side plugins that provide actual service to the client.