I am not a big fan of building extremely fine grained general purpose APIs for frontends. A lot of the burden of juggling with data and presenting it is shifted

I am not a big fan of building extremely fine grained general purpose APIs for frontends. A lot of the burden of juggling with data and presenting it is shifted to the UI layer. I am also not a big fan of building a composite API for "pages". Now you have a tightly coupled frontend/backend communication. What happens when we split the page or have to change the format of the data? Also the response of such an API can be quite big and nested. Ends up being a dump of data with poor documentation. I would try to find a middle path. Building composite APIs which have a concise purpose for the frontend but are modular enough to be reused across different areas of the application. Also, I feel that most of the problems discussed in the post are amplified when we have different groups working on the frontend and backend. If a single team is responsible for both the backend and frontend, API decisions are localized and can be changed as the development progresses.