Exactly, so unless you want to mish-mash all the login together, there will be an API. That's not the question.
The question is how you manage it's evolution. That's really up to you and how you want to manage interactions with those who consume your API, whether it's your fellow Dev next door or someone in a different company.
There are dozens of approaches.
I like versioning. I version up when I no longer want to maintain compatibility and add deprecation messages to relevant methods and classes. It's the core method of any software package and translates well particularly to DDD.
What's the alternative? Once I need to provide something everyone has to drop what they're doing and sync with me (or the other way around). We can't work asynchronously anymore and thus lose a core way of attaining agility. Any cohesive team should have the level of trust that people will respect the contract outlined by those pieces of code they output and provide timely notice so that others can handle their domain.
Refactor by IDE? That ensures code th as the won't break, not logic. If I need to add extra data on something a method returns, the IDE can make sure the code won't break but it can't speak to the actual handling of that. My consumer expects X and nothing more but if I need to add something else in a way they should be aware of, they'll get a new version of my method, the old will get a deprecation notice and everything is clear. There's no overhead and people can get to planning changes at their own pace alongside other priorities.
I agree. You list benefits of having an API. These arguments are valid. I do not want to question that APIs are an important tool, but I argue that they are often used without taking the costs into account.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Exactly, so unless you want to mish-mash all the login together, there will be an API. That's not the question.
The question is how you manage it's evolution. That's really up to you and how you want to manage interactions with those who consume your API, whether it's your fellow Dev next door or someone in a different company.
There are dozens of approaches.
I like versioning. I version up when I no longer want to maintain compatibility and add deprecation messages to relevant methods and classes. It's the core method of any software package and translates well particularly to DDD.
What's the alternative? Once I need to provide something everyone has to drop what they're doing and sync with me (or the other way around). We can't work asynchronously anymore and thus lose a core way of attaining agility. Any cohesive team should have the level of trust that people will respect the contract outlined by those pieces of code they output and provide timely notice so that others can handle their domain.
Refactor by IDE? That ensures code th as the won't break, not logic. If I need to add extra data on something a method returns, the IDE can make sure the code won't break but it can't speak to the actual handling of that. My consumer expects X and nothing more but if I need to add something else in a way they should be aware of, they'll get a new version of my method, the old will get a deprecation notice and everything is clear. There's no overhead and people can get to planning changes at their own pace alongside other priorities.
I agree. You list benefits of having an API. These arguments are valid. I do not want to question that APIs are an important tool, but I argue that they are often used without taking the costs into account.