Thats a great point. I do agree in theory it could be an anti-pattern but in my opinion it depends. For example with 42papers.com there were several places where business logic dictated the API response in short it was decoupled from the data-model. The way I handle this requirement is to use database views which behave exactly like other tables but could just as easily be called an internal API. The line between what is a data-model and what is an API is pretty blurred.
Another common case is when using "remote joins" with internal APIs (aka microservices) GraphJin can use data from the initial response to fan out and join responses from other APIs into the final response.
And finally for most startups adding this level of abstraction unless it's really needed is overkill and the data in the database maps pretty nicely to exactly what the needs of the UI.
Thats a great point. I do agree in theory it could be an anti-pattern but in my opinion it depends. For example with 42papers.com there were several places where business logic dictated the API response in short it was decoupled from the data-model. The way I handle this requirement is to use database views which behave exactly like other tables but could just as easily be called an internal API. The line between what is a data-model and what is an API is pretty blurred.
Another common case is when using "remote joins" with internal APIs (aka microservices) GraphJin can use data from the initial response to fan out and join responses from other APIs into the final response.
And finally for most startups adding this level of abstraction unless it's really needed is overkill and the data in the database maps pretty nicely to exactly what the needs of the UI.
Views are good indeed, implementing auto-api endpoints where there are no database tables. Read-only though. Thx for going into this.