While I agree with the conclusion, I'm struggling to find a coherent idea that leads to it.
You need an API. An API, a programming interface (as you also point out) hides implementation details and allows decoupling on whatever level you're exposing it. Having an API is essential regardless on whether you create an old-school monolith, a loosely coupled but still self contained system or you're providing your API externally as REST.
Whether you do CSR or SSR, in a specialised world it won't be the same people doing your data interaction as well as the pretty UX. One way or another there will be an API in-between, whether it's between people in the same team or different teams or different departments or if someone else entirely works on the UI, whether it's CSR or SSR.
"Every change in the system might break the clients which use the code." - that's the only really wrong thing I can point out. Any API, whether exposed externally or not, must be versioned and breaking changes must be made in a new version unless you are in a position to deprecate on the fly.
I agree that it's unlikely that the UX expert is not the same person as the backend engineer, but I argue that they should work together closely.
There are techniques like pair/mob/ensemble programming to facilitate this idea.
I also I agree on your last chapter: In every API you have to deal with versioning and breaking changes. That's why I recommend to avoid an API in the first place. ;-)
But how can you avoid an API ? Unless you're going for writing SQL queries in your display logic, you will have an API somewhere. Even if it's a simple service-like class that returns a dataset then it's technically an API. And as long as it's used by a developer other than you, there should be a contract of compatibility that ideally should include versioning (for the long run).
The issue you are raising is not solved by not having an API. It's solved (ideally) by replacing code-enforced contracts by communication. However, that's not practical in the long run because a clean API is self-documenting whereas direct communication backed by spaghetti code isn't.
Technically you might call it an API, because you have a technology switch between the frontend and the backend.
Think about an internal class in your backend module. Do you always evolve it in a backward compatible way? Hopefully not as you can use the refactoring capabilities of your IDE or the compiler or your unit tests help you to keep the internals consistent.
It's all the same with the frontend and backend commination. It's an internal implementation detail which you don't expose to the rest of the world.
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.
While I agree with the conclusion, I'm struggling to find a coherent idea that leads to it.
You need an API. An API, a programming interface (as you also point out) hides implementation details and allows decoupling on whatever level you're exposing it. Having an API is essential regardless on whether you create an old-school monolith, a loosely coupled but still self contained system or you're providing your API externally as REST.
Whether you do CSR or SSR, in a specialised world it won't be the same people doing your data interaction as well as the pretty UX. One way or another there will be an API in-between, whether it's between people in the same team or different teams or different departments or if someone else entirely works on the UI, whether it's CSR or SSR.
"Every change in the system might break the clients which use the code." - that's the only really wrong thing I can point out. Any API, whether exposed externally or not, must be versioned and breaking changes must be made in a new version unless you are in a position to deprecate on the fly.
I agree that it's unlikely that the UX expert is not the same person as the backend engineer, but I argue that they should work together closely.
There are techniques like pair/mob/ensemble programming to facilitate this idea.
I also I agree on your last chapter: In every API you have to deal with versioning and breaking changes. That's why I recommend to avoid an API in the first place. ;-)
But how can you avoid an API ? Unless you're going for writing SQL queries in your display logic, you will have an API somewhere. Even if it's a simple service-like class that returns a dataset then it's technically an API. And as long as it's used by a developer other than you, there should be a contract of compatibility that ideally should include versioning (for the long run).
The issue you are raising is not solved by not having an API. It's solved (ideally) by replacing code-enforced contracts by communication. However, that's not practical in the long run because a clean API is self-documenting whereas direct communication backed by spaghetti code isn't.
Technically you might call it an API, because you have a technology switch between the frontend and the backend.
Think about an internal class in your backend module. Do you always evolve it in a backward compatible way? Hopefully not as you can use the refactoring capabilities of your IDE or the compiler or your unit tests help you to keep the internals consistent.
It's all the same with the frontend and backend commination. It's an internal implementation detail which you don't expose to the rest of the world.
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.