Forward And Backward Compatibility

[Mahmod Ohner]

Forwardcompatibility or upward compatibility is a design characteristic that allows a system to accept input intended for a later version of itself. The concept can be applied to entire systems, electrical interfaces, telecommunication signals, data communication protocols, file formats, and programming languages. A standard supports forward compatibility if a product that complies with earlier versions can "gracefully" process input designed for later versions of the standard, ignoring new parts which it does not understand.

Forward compatibility for the older system usually means backward compatibility for the new system, i.e. the ability to process data from the old system; the new system usually has full compatibility with the older one, by being able to both process and generate data in the format of the older system.

Forward compatibility is not the same as extensibility. A forward compatible design can process at least some of the data from a future version of itself. An extensible design makes upgrading easy. An example of both design ideas can be found in web browsers. At any point in time, a current browser is forward compatible if it gracefully accepts a newer version of HTML. Whereas how easily the browser code can be upgraded to process the newer HTML determines how extensible it is.

The introduction of FM stereo transmission, or color television, allowed forward compatibility, since monophonic FM radio receivers and black-and-white TV sets still could receive a signal from a new transmitter.[1] It also allowed backward compatibility since new receivers could receive monophonic or black-and-white signals generated by old transmitters.[citation needed]

HTML is designed to treat all tags in the same way (as inert, unstyled inline elements) unless their appearance or behavior is overridden; either by the browser's default settings, or by scripts or styles included in the page.[8] This makes most new features degrade gracefully in older browsers. One case where this did not work as intended was script and style blocks, whose content is meant to be interpreted by the browser instead of being part of the page. Such cases were dealt with by enclosing the content within comment blocks.[9]

Because there is no mandatory upgrade of computers or web browsers, many web developers use a graceful degradation or progressive enhancement approach, attempting to make newly-created websites that are usable by people who have turned off Javascript or who have old computers or old web browsers or on a slow connection, yet still taking advantage of faster hardware and better JavaScript support in more modern web browsers, when available.[10]

Each of the three most common 12 cm optical media formats (CD, DVD, and Blu-ray) was first released in read-only form years before writable forms were available. Within each format, there is both forward and backward compatibility, in that most older read-only drives and players can read (but not write) writable media in the same format, while read/write drives can read (but not write) old read-only media. There is no forward compatibility between formats; a CD player, for instance, can't read a DVD (a newer format), not even the audio tracks. There may be backward compatibility for better marketability (such as a DVD player playing an audio CD), but it is not intrinsic to the standards.[11]

Some products are not designed to be forward compatible, which has been referred to as NUC (not upwardly compatible). In some cases this might be intentional by the designers as a form of vendor lock-in or software regression.

For example, a cubicle producer considers changing their cubicle design. One designer promotes changing the footprint from 4 foot square to 1.2 meter square. Immediately, the sales manager calls "NUC" and the problem is understood: if the footprint changes and existing customers are considering buying more from the producer, they will have to fit a different sized unit in an office designed for the 4 foot square cubicle.

Planned obsolescence is a type of upward compatibility, but rather than adopting a policy of backwards compatibility, companies adopt a commercial policy of backwards incompatibility so that newer apps require newer devices.

Is one of the scenarios called "backwards-compatibility" and the other "forward-compatibility" in an arbitrary way?Otherwise, if both can be called both ways depending on the reference, then, is client in Scenario A backwards-compatible and server forward-compatible or the other way around?

When something can still connect to a previous version (I assume client - server in A) it is "backwards-compatible" with that previous version. "Forwards compatibility" is not often used in English, but it means the opposite.

You are asking about APIs but I am going to answer in terms of messaging schemas in particular kafka. A subset of the concepts of forward/backwards compatibility in this messaging scenario is directly translatable into the same compatibility concepts for a regular API. When it comes to event driving microservices that exchange messages over a messaging technology such as kafka this sort "messaging API" compatibility problems is the only, and more complex form, of the "microservices API" compatibility problem in your question.

With Kafka there is a schema registry service. You can register a schema that defines the allowable json/avro/protobuf messages for the topic. You can evolve a schema by editing it and it retains a history of versions of the schema. The schema registry has a full API. Its use is optional. You can set a compatibility level for the schemas registered against a topic that are described here. As it is talking about validating/rejecting updating the schema of a topic when attempting to register a new schema based on the following schema compatibility being assigned to the topic. I have edited the text slightly for clarity:

The NONE is zero protection. You can register a new schema with no compatibility and you hope that all producers and all consumers are simultaneously updated as being compatible. Older producers will poison the topic. Old consumers will crash trying to read the messages.

The FULL is obvious. No breaking changes are allowed you may add optional fields that might be present. Older producers that do not supply the optional fields do not break older consumers who are not expecting it nor new consumers. New producers do not break old consumers as they will ignore the optional field when reading data out of the message payload.

It is often the case that it is the "data supplier" who is being updated and that it "supplies" the latest version of the data. It is often the case that we don't want to break older "data readers". In the case of kafka it often the case the data producer team who updates the topic schema. Compatibility is whether they will break the multiple consumers. In which case we need that the older schemas are "forwards" compatibility with the newer schemas. Where the real complexity kicks in is when we have older producers sending messages to the same topic concurrently with newer producers sending newer messages to the same topic.

I do not think that being a native English speaker is really an issue here it is a matter of having clear definitions. In the case of simple APIs with a single "supplier" then we we can talk about "forwards compatibility" of the consumer of the API or "backwards compatibility" of the new API to older readers. We naturally talk about updating our APIs in a "backwardly compatible" manner. Yet it is really the "forwards compatibility" of all your existing API consumers that you are trying to maintain. It is a matter of perspective.

LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.

Compatibility is hard. Depending on the nature of your component/service it could be very unstable by nature. Let's consider an Adapter Pattern for instance or APIs that integrate 2 other APIs, easily they will be breaking on every API change at any side. Even with mundane, regular APIs and Services, compatibility can be very hard to achieve. So, what should we do? Break all the things all the time? Be backward compatible with all versions forever(Which there are a huge price and source of complexity) or maybe there is a middle ground approach we could take? Backward compatibility is only one part of the story the whole compatibility story is much more complex involving Forward compatibility, Isolation, Interfaces, and lots of subtle details. There are the different contexts where software can live so under a microservices in one thing, shared application code is another, shared lib or company framework is completely different stories as well. IMHO at the scale, it does not matter if your consumer is internal or external consumers. Depending on the relationship of the piece of software you might be able to say yeah go there and refactor you code, but maybe not. So this blog post will expand this concept a bit more and show in a video how we can deal with some of these challenges. The last time I wrote about this subject was 6 years ago. I felt was time to talk about it again.

Backward compatibility is easy to understand. Not so easy to maintain. The idea is your software works with the previous version, so the question is what works means? Work means: Functional with no bugs and also no breaking change, so we need to understand what is a breaking change and what is a non-breaking change. For instance:

Breaking changes can be manifested in several other ways like (A) Ordering of the results you return in a List. (B) Data format you were operating let's say you change from DD/MM/YYYY to YYYY/MM/DD. (c) Data format, let's say we change from XML to JSON. Also, it could be in several other ways, it's easy to break something. There are basically a couple of different possible ways we have to deal with backward compatibility:

3a8082e126