3 ms·

> 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 t

> 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.

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.