>> the culture of changing an API is much more understood as something that must be communicated and processes are more rehearsed
> You're just making this up. There are thousands of incidents every day because someone changed an API without communicating to every stakeholder.
What you wrote isn't a contradiction of what I wrote. I wrote "more understood" not "perfectly solved problem."
> "Services are better than databases because service owners are better at communicating changes than database owners" isn't a very compelling argument.
Except they are because the tooling is better. I can check calls to an API endpoint using the same tooling that I would for checking end user API calls. I can push out comms to use the new API, I can confirm calls go to 0 before deleting the old endpoint.
For checking that a table or column is being accessed before changing / deleting it? Fuck, I don't actually know how I'd orchestrate that. And once I've made that change (vs when I make an API change), well, I hope I got it 100% correct because reverting that change is harder.
> You're just making this up. There are thousands of incidents every day because someone changed an API without communicating to every stakeholder.
What you wrote isn't a contradiction of what I wrote. I wrote "more understood" not "perfectly solved problem."
> "Services are better than databases because service owners are better at communicating changes than database owners" isn't a very compelling argument.
Except they are because the tooling is better. I can check calls to an API endpoint using the same tooling that I would for checking end user API calls. I can push out comms to use the new API, I can confirm calls go to 0 before deleting the old endpoint.
For checking that a table or column is being accessed before changing / deleting it? Fuck, I don't actually know how I'd orchestrate that. And once I've made that change (vs when I make an API change), well, I hope I got it 100% correct because reverting that change is harder.