Let's imagine that we have two apps:
- App A - a server or a data source - this app should initiate the process.
- App B - a client or service - this app serves the specific aim.
Initially, App A sends some data to App B (just HTTP request) and App B then sent a request to App A in order to get additional info that App B needed for the process of the request from App A. It sounds like it was too chatty and it was it.
Once upon a time, we decided to fix this communication approach in a way where App A will send all required info in the first request and App B will not need to request any additional info. Sounds reasonable, doesn't it?
Here, one problem pops up in our heads - backward compatibility. Because both apps are under our control, we decided that we can make breaking changes and not support both implementations at the same time. It sounded doable - proper testing, sync deployment, not a big deal...
The day of deployment had come and we executed your plan. Test on production - works fine, all sides are happy.
But in 2 days our operation team reported that something was wrong with data acquisition. Here I have to add some technical details: App B generates an HTML page that has a link to React app, and this page goes to the advertising network (a tag in the DSP world). The React app also was changed because the interface and corresponding data structure were change. Thus tags that are live had links to the updated React app but this new version cannot work with old data structure.
We had to roll back changes for React app and use an explicit version in the new implementation.
What is your approach in such a situation? Do you support old versions of interfaces or small "fire" can be acceptable?
Top comments (0)