DEV Community

Discussion on: Do you really need an API?

olibutzki profile image
Oliver Libutzki

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.

Thread Thread
andreidascalu profile image
Andrei Dascalu

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.

Thread Thread
olibutzki profile image
Oliver Libutzki • Edited

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.