3 ms·

> Roll out your new API, and replace your old API's implementation with a proxy that calls through to the new API. I don't think you understood the problem you

> Roll out your new API, and replace your old API's implementation with a proxy that calls through to the new API. I don't think you understood the problem you're commenting on. The problem is not that you have a new fancy API version you expect users to consume. The problem is that you need to shut down the old API without causing customer or business impact. It makes little to no sense to pile up technical debt and extra maintenance work to keep around a specific configuration in an API Gateway if your goal is to get people to stop using it so that you don't have to maintain N+1 versions of your service. Your vague observation of how much work a API Gateway config takes is meaningless because you have no idea the impact of any change to the API will have on the older version fed through adapters. I mean, even changes in performance can be disastrous. And even under the unlikely case a API Gateway applying a transformation is enough to sunset the old version,how is that an improvement on maintenance? You now have a new abstraction layer that requires testing and maintenance, and a multitude of scenarios you need to validate independently whenever a change is made. And what answer do you have to the question on what to do if a commit works in the new version of the API but introduces a regression on the old version? The truth of the matter is that there are only a couple of sunsetting strategies that work, which is: * In internal service calls, negotiate a sunsetting strategy with other internal teams. The deadline will invariably be pushed forward each and every single time. * In external service calls, you can announce to the world you're sunsetting the API and advertise it on Times Square,and still a hefty share of your customer base won't know and will still be caught by surprise. The only strategy that works is graceful degradation: start returning 404s and 410s periodically and dial it up until clients feel the need to move on. Dial it back when appropriate to get your point across without denying service, but understand that it will be impossible for some clients to change.

oasisbob 2y ago
The post you're replying to is describing a straightforward implementation of the strangler pattern. It's a valid and useful technique. Even if you disfavor it, I don't see why you feel the need to judge the comprehension skills of the commenter. https://www.redhat.com/architect/pros-and-cons-strangler-architecture-pattern https://www.redhat.com/architect/pros-and-cons-strangler-arc...
- chipdart 2y ago
  > The post you're replying to is describing a straightforward implementation of the strangler pattern. I'm not sure you are aware the strangler pattern is completely irrelevant to the problem of shutting down old versions of APIs still in use, specially when the goal is to shed maintenance needs. Just because you are confident you can serve the same requests through an adapter, that does not mean you have less code to maintain and less work to do. Quite the opposite. And now your services also have to deal with more constraints as you're now bounded to comply with far more scenarios, some conflicting, from the same code base. Talking about strangler fig patterns makes as much sense as blabbering about interfaces and dependency injection when talking about deleting old code. Irrelevant.
michaelt 2y ago
> Your vague observation of how much work a API Gateway config takes is meaningless because you have no idea the impact of any change to the API will have on the older version fed through adapters. I don't think you've understood what I'm proposing here. When I release the V2 public API and invite my customers to code against it, they're going to start calling the methods I offer and expecting the response fields I promise. If I make incompatible changes to the API I'll break their stuff and they'll be understandably mad at me. All I have to do, therefore, is write an adaption layer that adapts the V1 public API which is stable and never needs any new features or fields because it's deprecated to the V2 public API which is also stable because fields and methods do not disappear on public APIs. I don't know what an "API Gateway" is - given that you seem to think it's a lot of work to set up and maintain and that it can't accomplish this task, it's probably not the right tool for the job?
- devin 2y ago
  An assumption you're making here that you can even write an adapter layer for the V2 API. There may be things you wish to _remove_ in the V2 API. V2 does not always mean "add more stuff", it can often mean rethinking "what stuff" is provided.
  - michaelt 2y ago
    Yes - that's why I included the proviso "if you're truly replacing your API with a new, more capable version" If your intention is to remove features and fire the customers who are relying on them, that's a different matter.
    - chipdart 2y ago
      > If your intention is to remove features and fire the customers who are relying on them, that's a different matter. No. That is not a different matter. That's basically the whole problem being discussed, and the topic of the blog post you're discussing.
- chipdart 2y ago
  I don't think you figured out the point I presented you. The whole point is that new API versions are rolled out because the changes that need to be introduced are incompatible with old APIs. Otherwise there won't be a need for a new API, is there? The whole reason there are different APIs is that they are already incompatible. If you could handle new usecases with adaptors, you'd already be using them. But you aren't. > I don't know what an "API Gateway" is Right, and here you are lecturing on API design and present solutions to API problems.

oasisbob 2y ago

The post you're replying to is describing a straightforward implementation of the strangler pattern. It's a valid and useful technique. Even if you disfavor it, I don't see why you feel the need to judge the comprehension skills of the commenter. https://www.redhat.com/architect/pros-and-cons-strangler-architecture-pattern https://www.redhat.com/architect/pros-and-cons-strangler-arc...

chipdart 2y ago
> The post you're replying to is describing a straightforward implementation of the strangler pattern. I'm not sure you are aware the strangler pattern is completely irrelevant to the problem of shutting down old versions of APIs still in use, specially when the goal is to shed maintenance needs. Just because you are confident you can serve the same requests through an adapter, that does not mean you have less code to maintain and less work to do. Quite the opposite. And now your services also have to deal with more constraints as you're now bounded to comply with far more scenarios, some conflicting, from the same code base. Talking about strangler fig patterns makes as much sense as blabbering about interfaces and dependency injection when talking about deleting old code. Irrelevant.

michaelt 2y ago

> Your vague observation of how much work a API Gateway config takes is meaningless because you have no idea the impact of any change to the API will have on the older version fed through adapters. I don't think you've understood what I'm proposing here. When I release the V2 public API and invite my customers to code against it, they're going to start calling the methods I offer and expecting the response fields I promise. If I make incompatible changes to the API I'll break their stuff and they'll be understandably mad at me. All I have to do, therefore, is write an adaption layer that adapts the V1 public API which is stable and never needs any new features or fields because it's deprecated to the V2 public API which is also stable because fields and methods do not disappear on public APIs. I don't know what an "API Gateway" is - given that you seem to think it's a lot of work to set up and maintain and that it can't accomplish this task, it's probably not the right tool for the job?

devin 2y ago
An assumption you're making here that you can even write an adapter layer for the V2 API. There may be things you wish to _remove_ in the V2 API. V2 does not always mean "add more stuff", it can often mean rethinking "what stuff" is provided.
- michaelt 2y ago
  Yes - that's why I included the proviso "if you're truly replacing your API with a new, more capable version" If your intention is to remove features and fire the customers who are relying on them, that's a different matter.
  - chipdart 2y ago
    > If your intention is to remove features and fire the customers who are relying on them, that's a different matter. No. That is not a different matter. That's basically the whole problem being discussed, and the topic of the blog post you're discussing.
chipdart 2y ago
I don't think you figured out the point I presented you. The whole point is that new API versions are rolled out because the changes that need to be introduced are incompatible with old APIs. Otherwise there won't be a need for a new API, is there? The whole reason there are different APIs is that they are already incompatible. If you could handle new usecases with adaptors, you'd already be using them. But you aren't. > I don't know what an "API Gateway" is Right, and here you are lecturing on API design and present solutions to API problems.