Long time software architect, CTO Authress, creating application security plug-ins for any software application with Authress. Talk to me about security in microservices or service authorization.
0 . On the backend
This is my favourite approach, if you can afford it. If the backend returns data in exactly the structure we want, there is nothing we need to do. While this might sound unrealistic in many cases, e.g. when working with public REST APIs, it is also quite possible to achieve in enterprise applications. If you are in control of the backend and have an endpoint that returns data for your exact use-case, prefer to deliver the data the way you expect it.
The reason is that they think they control all the use case when they write the service API. The truth is they don't and by coupling the API to the UI, you limit the flexibility and use cases that the API can support. The API should think only about exposing the right data with the right queries and never about the best way for one particular client to consume the data.
The only caveat to this is, if every consumer, for some N > 10, which always need the same data in the same way, then you can argue justifiably that the API data schema needs to be adjusted.
The best approach is assume that the API owner and the UI owner are very different companies. If as a company you wouldn't opt for changing the API to satisfy one UI client, then the answer is don't do it even if you own both.
I generally agree, at least for public APIs. For enterprise apps, we often make APIs for a specific use-case. It feels a bit like premature optimization to deliver something the frontend has a hard time working with, just for the sake of being decoupled. It's not wrong to give the frontend the structure it needs, and reconsider the structure once more use-cases arise.
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.
Frequently junior developers prefer this option:
The reason is that they think they control all the use case when they write the service API. The truth is they don't and by coupling the API to the UI, you limit the flexibility and use cases that the API can support. The API should think only about exposing the right data with the right queries and never about the best way for one particular client to consume the data.
The only caveat to this is, if every consumer, for some N > 10, which always need the same data in the same way, then you can argue justifiably that the API data schema needs to be adjusted.
The best approach is assume that the API owner and the UI owner are very different companies. If as a company you wouldn't opt for changing the API to satisfy one UI client, then the answer is don't do it even if you own both.
I generally agree, at least for public APIs. For enterprise apps, we often make APIs for a specific use-case. It feels a bit like premature optimization to deliver something the frontend has a hard time working with, just for the sake of being decoupled. It's not wrong to give the frontend the structure it needs, and reconsider the structure once more use-cases arise.