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

Let’s be honest, changing both the Backend and the Frontend is great to very quickly prototype something. It’s also super easy to have one pull-request containing both changes if you use a monolith repository.

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

As soon as you have one important user using your application, you are not too small. Especially when you don’t have many clients, you need to be very careful at giving them an amazing experience, and that starts by not forcing them to re-install or update your application when they want to use it.

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

One argument is that you don’t need to think about backward compatibility if you deploy both your frontend and backend at the same time. This is kind of true for backend-generated applications but it definitely isn’t in these very common scenarios:

• 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?

Ideally, while you work on your mobile application, you’d use the production API (or at least deployed). This ensure that the feature you are working on is going to be available, regardless on when you work on this frontend will be deployed.

Not deployed yet?

What’s blocking it? Can you help to have this API deployed?

Not started yet?

That happens often: the backend and frontend are different work streams (different teams) and they have a different pace. The beauty of APIs is that they define contracts: you can design first, “mock” them and implement them later. Tools like Apiry can help your team collaborate via their “fake APIs”.

Not designed yet?

Go and do it. Think about it as if you were providing an API to a 3rd party. Not doing so often results in having weirdly designed and named API that nobody wants to change because they don’t know what is using it.

How can we identify BC breaks?

As far as I know, there are little tools (for now — and please let me know if I’m wrong) that help us capture such changes in an automated manner.

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.

Sam.