Multi component applications: work practices & backward compatibility

Let’s picture the scene. Your product is built on a mobile (or web) application and an API. Whether you are using a monolith repository or not, you will have two different applications your development team will work on: the front and the back.

Backward incompatible changes

On the other hand… it means it’s very simple to introduce backward incompatible changes (also known as “BC breaks”). Introducing a BC break means that your API will return something that is not compatible with the previous version of your frontend.

Such change is typically changing an API endpoint name (imagine /user/register to /signup) but it can be much more subtile. If you decide to remove a field from the API, anything relying on this field will break (and note that it can dramatically crash the applications in some cases). Even trickier, before your API returned empty lists and now it returns null (by the way, this exact example is the reason why the Monzo Bank went down for hours).

But I’m too small to care

If you need to use a metric to be convinced, use the percentage of unhappy clients instead of the absolute number of clients :)

But I’m deploying both at the same time

  • You have an SPA (Single Page Application, i.e. Angular, React, ...). When loaded, your SPA doesn’t load anything else than the API itself. So if a user has loaded the page and you update the API containing a BC break… the next action the user is going to do won’t be very successful for them

    And let’s not even talk about the fact that your assets are very likely to be cached in many places.
  • You have a mobile application. That’s the simplest example: “deploying” an application to a “store” takes up to a few weeks. Even after any review phase, from the moment the application is sent to the Apple Store or Google Play Store, a few hours, days and even weeks can be needed for the updates to be propagated (some users won’t have auto-update activated, some won’t have decided they wanted a new version as they like that one, etc…)

Should developers work on both the frontend and backend at the same time?

Not deployed yet?

Not started yet?

Not designed yet?

How can we identify BC breaks?

Nevertheless, changing a little our work practices can drastically change our approach: use the deployed Backend while working on the Frontend. While working on the Backend use the deployed Frontend. (replaced “deployed” by “old” if it makes more sense to you).

An interesting area to explore might be around integration tests. You could run your “old” tests against your new API.




Software Engineering. Containers. APIs & IPAs.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store