3 ms·

Sure, but with HTML all I can do is render it. With a well designed JSON API I can wrangle and mangle it and use the same data in many places or different apps

Sure, but with HTML all I can do is render it. With a well designed JSON API I can wrangle and mangle it and use the same data in many places or different apps even.

marcosdumay 3y ago
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.
andsoitis 3y ago
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).
the_gastropod 3y ago
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 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.
hannofcart 3y ago
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.

Sure, but with HTML all I can do is render it. With a well designed JSON API I can wrangle and mangle it and use the same data in many places or different apps even.

marcosdumay 3y ago

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.

andsoitis 3y ago

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

the_gastropod 3y ago

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

hannofcart 3y ago

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.