Other times, centralizing it on the server might be best.
Some apps lend themselves much more to doing a lot of interesting work on the client (Figma is an example, going so far as to implementing their own rendering engine, for instance).
tl;dr:
Your JSON api has to figure out:
- How to predict and enable all possible workflows
- How to avoid N+1 requests for awkward workflows
- How to test functionality, performance, and security of every possible request
- How to change the API without breaking the existing workflows
- How to prioritize API changes between internal and community requirements
- How to document everything so that all parties can get stuff done
And on then on the front-end, you have to figure out:
- How to collect all the data needed to render a page
- How to optimize requests to multiple endpoints
- How to avoid using API data fields in unintended ways
- How to weigh the benefit of new features against the cost of new API requests
He goes on to point out that the "re-use" value of an api endpoint is extremely low. You can re-use virtually all the code that produced that endpoint to produce a different one with a different structure for precisely what you need in this new use-case.
Then add a layer on top of that that 'renders' the same structure into multiple formats: JSON or HTML as needed.
Expose each of these view layers as a different endpoint in your service.
HTML you can render as-is. JSON needs additional processing logic client-side.