0

In my company, we're using Spring Boot to implement backend API and React to implement frontend including Web interface and Android/iOS apps.

Since our product is an Enterprise software, customers actually have to pay to get the latest backend API to deploy on their own servers. However, our mobile apps are regularly updated on the App Store. This leads to a situation where the mobile apps on end-users' devices may be the newer version while the backend API on the customer's machine is the older one. We plan to support up to 3 minor version backward, meaning FE 5.4 will support up to backend 5.2.

The backend does have an endpoint to return the current version number. However, I'm a bit clueless as to how our frontend implementation can maintain backward compatibility with older API versions as we add new features and may introduce breaking changes in backend API.

I completely understand there might not any beautiful solutions for this problem. I'm hoping if you've gone through this pain, you can share your experiences about what you've tried, the final approach that you took and the potential pitfalls to look out for.

I'm sure myself and other people who's running into this issue would be really grateful :).

Improve this question
4
  • 1
    Frontends and backends are typically an integrated design. You either have to keep them synchronised (by ensuring neither side is updated ahead of the other), or you have to manage the extreme complexity and limitations that arise from lack of synchronisation. There's not really any other trick.
    – Steve
    May 10, 2020 at 17:14
  • @Steve: Thanks for the comment Steve. I understand there might not be a beautiful solution. I was hoping if someone who has gone through this pain can share their experiences about how they did that, what they tried and the potential pitfalls to look out for :D
    – JamesBoyZ
    May 10, 2020 at 17:35
  • 2
    @JamesBoyZ, a major thing to keep in mind is that you keep testing your frontends also against a number of old versions of the backend to ensure no features that should be available are suddenly broken. Test at least against the oldest supported version, the most-deployed version, the current and the last-before-current versions. And any version where a risk-analysis of the new features tells you they might be impacted.
    – Bart van Ingen Schenau
    May 10, 2020 at 18:06
  • @BartvanIngenSchenau: Thanks for the pointers Bart. We will definitely keep that in mind. Perhaps, it's a good idea to maintain as many backend deployments on the DEV server as the number of versions we plan to support. Then we can have some automated tests :)
    – JamesBoyZ
    May 10, 2020 at 18:40

2 Answers 2

Reset to default
3

Given this licensing model, you need to provide indefinite front-end support unless you want to force customers to upgrade their back-end (or switch to a competitor.)

One option would be to support only a limited number of historic back-end APIs with the front-end app but provide legacy versions as separate apps. Users will have to install a legacy version of the app when the new version doesn't support the old API anymore.

Another option would be to support every old API version, but to make API changes very sparingly, for example by implementing a stable base APIs and a set of feature APIs which are introduced with one back-end version and possibly deprecated with a later one.

If your license contract defines an end-of-support, you might be able to argue that API support in the app ends with or some time after end of support for a back-end version.

Improve this answer
3
  • Thanks for the pointers Hans :). We plan to support up to 3 minor versions of the backend backward. The legacy app option you mentioned is really great for stubborn customers though :D.
    – JamesBoyZ
    May 10, 2020 at 18:28
  • @JamesBoyZ, if you are not offering free upgrades of the backend, I expect you will be put under pressure to support way more versions (and also old major versions) in your frontend than that.
    – Bart van Ingen Schenau
    May 11, 2020 at 5:39
  • @BartvanIngenSchenau: I think you're right :). We're planning the number low so that when we go into the room for negotiation with business users, the number won't increase too much but I do expect that to happen. Regarding the updates, most of our clients are big hospitals and government agencies. To them money is not an issue but they have a very lengthy process for getting a patch approved even when they do want to get the latest version. I guess we'll have to live with that...
    – JamesBoyZ
    May 11, 2020 at 6:28
1

The most useful technique for designing an API that allows long term evolution is following REST constraints. The REST constraints your API design to techniques that will allow you to evolve your API, while maintaining long term evolution. Some of the higher REST maturity principles that are often overlooked, like uniform resources identifier, HATEOAS, and content type negotiation often seems like a lot of work and makes very little sense when you just take a single snapshot of an API at a particular version, but these constraints actually are what allowed future changes to be made while carrying as much of the old clients for as long as possible which can even be forever. These constraints are what allowed different client and server versions to coexist with minimal breakages and with careful design they can allow servers to deploy a wide range of updated behaviours for old clients without requiring the old clients to be updated.

To be clear, REST does not solve all problems with evolving API, and you do need to make the effort to maintain REST constraints throughout and maintaining backward and forward compatibility, but ensuring that your API follows as much as possible of the REST constraints allows many of these problems that seemed impermeable to be solvable and in a fairly standardized way.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.