Database Reference
In-Depth Information
incompatible version. And worse, that means that you have no way of distributing bug
fixes to them. So, to quote the old American Express commercials, what will you do?
Option 1: The Perpetually Compatible Application
One way to approach the problem is to keep your application perpetually back-
compatible with every version of the API that has ever existed. It's not impossible,
especially if you're clever about it. What you want to avoid is sprinkling your API
integration code with conditionals everywhere. A more modular approach is to use a
protocol to define your API functions, and use different implementing classes to handle
different API versions. Then on first connect to the server, you can figure out which
API version you're talking to, and provision the correct implementing class to talk to it.
On the surface, this doesn't look like a bad option, at least until you start thinking
through to the next level of code. Suppose version 1.0 of our BuggyWhipChat appli-
cation connects to version 1.0 of the backend API, and supports features A and B.
Version 2.0 of the app connects to version 1.1 of the backend API, and supports A, B,
and C. You don't know at first glance if the application is going to connect to a 1.0 or
1.1 backend, so you have to conditionalize your UI and business logic—not just your
API interface code—to handle either possibility. It can get even worse when features
on a single screen have to be conditionalized. You can end up with an app that is
essentially thousands of “if” statements flying in close formation.
Now multiply that times 5 or even 10 different backend API versions, and you can
imagine how messy your application code can end up. Depending on how aggressive
you are about sunsetting support for older server versions, it can quickly become a
nightmare, particularly for testing, as you'll have to regression-test all new application
versions against all the supported server versions.
And think about what happens if you do sunset support for an old server version. What
happens to the customers who refuse to upgrade? The next time their application up-
dates from the App Store, it will break. I suppose that's one strategy to get your cus-
tomers to keep up their support contracts, but it may not be a very politically popular
one.
(Non-)Option 2: The Perpetually Compatible Server
A little thought will make it clear that trying to place the compatibility requirement on
the server side is a non-starter. Remember, the problem is not with an out-of-date client,
since we can pretty much assure that the client will always be the latest version (and
enforce it with upgrade messages inside the app that force the user to upgrade before
proceeding). The problem is with an out-of-date server, which can't support all the new
or changed features of the app.
