3 ms·

This sounds a good idea in theory, but not sure about in real world. Consider having 4 versions of API, will you create 3 levels of proxies or each time re-wri

This sounds a good idea in theory, but not sure about in real world. Consider having 4 versions of API, will you create 3 levels of proxies or each time re-write your old proxy? Sometimes, more capable mean additional side effects not existing in old contract (e.g. send an email about order), in that case your new API should be flexible to accommodate configuration of side effects, adding more maintenance cost to your eng. org

tuyguntn 2y ago
also, the assumption here is "more capable = same features + something new (no removals)", sometimes you have to delete some features as part of new API (e.g. stop creating audit log entry for an action).
- tikhonj 2y ago
  Conceptually, we should see deprecating a feature as a separate question from moving to a new API. So in this scenario, you would manage deprecating functionality in the same way regardless of whether you're also rolling out a new API at the same time.
michaelt 2y ago
> This sounds a good idea in theory, but not sure about in real world. > Consider having 4 versions of API, will you create 3 levels of proxies or each time re-write your old proxy? In the real world if you insist on breaking your paying customers' processes and products over and over again, pretty soon you won't have any paying customers any more, and you'll be free to make incompatible changes as often as you want.
- chipdart 2y ago
  > In the real world if you insist on breaking your paying customers' processes and products over and over again, (...) You do not break anyone's experience by releasing a new version that's voluntarily adopted by your paying customers. You are also somehow inexplicably assuming that your paying customers didn't ended up being paying customers because you adapted to customer demands and added the value that was important enough to them that they decided to pay for it. I can tell you for a fact that there are paying customers for APIs that pay to use both the latest API and older versions. More often than not, they still consume old versions because they cannot spare the manpower to update some clients/services. On top of that,the problem grows a few orders of magnitude when you open your APIs to the public. Even when you control the only clients to your APIs, it's impossible to get some end users to upgrade their software. Some still run old OSes that have long been unsupported, and some are even physically unable to run updates.
- tuyguntn 2y ago
  > In the real world if you insist on breaking your paying customers' processes and products over and over again, pretty soon you won't have any paying customers any more Business 101, your profit is in higher margin or lowering your spending/cost. If your business is stable and making money your customers feel safe and are happy. Deprecation lowers your cost (system complexity, less maintenance, dev time -> new features, new revenue streams). If you have an almost infinite resources then of course why not, you can support all possible API versions (there are few companies who can afford it and doing it at scale, AWS and Win32 APIs)

tuyguntn 2y ago

also, the assumption here is "more capable = same features + something new (no removals)", sometimes you have to delete some features as part of new API (e.g. stop creating audit log entry for an action).

tikhonj 2y ago
Conceptually, we should see deprecating a feature as a separate question from moving to a new API. So in this scenario, you would manage deprecating functionality in the same way regardless of whether you're also rolling out a new API at the same time.

michaelt 2y ago

> This sounds a good idea in theory, but not sure about in real world. > Consider having 4 versions of API, will you create 3 levels of proxies or each time re-write your old proxy? In the real world if you insist on breaking your paying customers' processes and products over and over again, pretty soon you won't have any paying customers any more, and you'll be free to make incompatible changes as often as you want.

chipdart 2y ago
> In the real world if you insist on breaking your paying customers' processes and products over and over again, (...) You do not break anyone's experience by releasing a new version that's voluntarily adopted by your paying customers. You are also somehow inexplicably assuming that your paying customers didn't ended up being paying customers because you adapted to customer demands and added the value that was important enough to them that they decided to pay for it. I can tell you for a fact that there are paying customers for APIs that pay to use both the latest API and older versions. More often than not, they still consume old versions because they cannot spare the manpower to update some clients/services. On top of that,the problem grows a few orders of magnitude when you open your APIs to the public. Even when you control the only clients to your APIs, it's impossible to get some end users to upgrade their software. Some still run old OSes that have long been unsupported, and some are even physically unable to run updates.
tuyguntn 2y ago
> In the real world if you insist on breaking your paying customers' processes and products over and over again, pretty soon you won't have any paying customers any more Business 101, your profit is in higher margin or lowering your spending/cost. If your business is stable and making money your customers feel safe and are happy. Deprecation lowers your cost (system complexity, less maintenance, dev time -> new features, new revenue streams). If you have an almost infinite resources then of course why not, you can support all possible API versions (there are few companies who can afford it and doing it at scale, AWS and Win32 APIs)