6 ms·
Very interesting. How did you deal with the issue where the old API had some feature X that wasn't supported in the new API but some customers depended on featu
by throwthrow564 5y ago
Very interesting. How did you deal with the issue where the old API had some feature X that wasn't supported in the new API but some customers depended on feature X?
- scv119 5y agoI guess that a hard question for user facing API: you need to support both the old and the new features during the migration. In our case, this design principle mostly applied to our internal APIs. Particularly, we designed our internal sub components (consensus protocol, particularly) in a way we can swap it without any downtime.
- haimez 5y agoRight. So it seems you did a lift and shift over two years without changing the basic API surface. That’s ok, but stability of requirements throughout a rearchitecting project is a luxury and not the norm