Yep. In some cases it might be better to keep a local representation of the data and have different view and business logic all on the client to create a presentation & interaction experience for the user.

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).

You can wrangle and mangle the original data much better than whatever JSON you decided to send. And you can make different apps with your database too.

Here's a pretty good essay by Max Chernyak on why using a generic JSON api to power your application's front end is a bad idea. https://max.engineer/server-informed-ui

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.

The way around this is to have a layered approach in the backend. A business logic layer which generates some data, presumably structured in whatever way is canonical for the language you use.

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.