031: Using shim on API to prevent breaking changes
In 2021 Twilio sent a termination email on their Fax services. I was consulting as the CTO in a credit bureau that was in the start of an acquisition process with Equifax Canada. There was just no time to "waste" on changing provider and rewriting this part of the system to satisfy the new provider API.
Would have been grand if the provider would have offered a shim that replicated Twilio's API and map that to their own API. Imagine how many companies needed to rewrite this part at the same time. Offering this as the provider that receives X thousands new customers would have been a superb engineering experience.
So maybe we can apply this concept internally as well. When a team needs to introduce breaking changes, a good solution might be for them to provide a shim over the old API so no other teams need to do anything.
This is obviously a tad dangerous and might introduce some technical debt. But as everything, it depends.
Would have been grand if the provider would have offered a shim that replicated Twilio's API and map that to their own API. Imagine how many companies needed to rewrite this part at the same time. Offering this as the provider that receives X thousands new customers would have been a superb engineering experience.
So maybe we can apply this concept internally as well. When a team needs to introduce breaking changes, a good solution might be for them to provide a shim over the old API so no other teams need to do anything.
This is obviously a tad dangerous and might introduce some technical debt. But as everything, it depends.
Creators and Guests
Host
Dominic St-Pierre
Go system builder - entrepreneur. I've been writing software systems since 2001. I love SaaS, building since 2008.
