Hmm. Of course it can be true in certain circumstances, but I would be surprised if on average the (compressed) size of the js bundle + subsequent JSON API request is smaller than html * the number of pages visited in a session.
Even if you are careful (and most sites are definitely not) overfetching JSON can easily happen due to API's not delivering exactly what you need etc.
Plus, in many circumstances both js bundle + json or HTML text gets dwarfed by images or other media.
Imagine rendering some complex data model to image on server vs downloading json and rendering it on client. Yes, SVG does exist, but it doesn’t cover all cases.
> Even if you are careful (and most sites are definitely not) overfetching JSON can easily happen due to API's not delivering exactly what you need etc.
I've seen the term BFFE used: Backend for Front-end, which is where the backend is a set of APIs, and for those specialised requests that the front-end makes, endpoints are created on (maybe) a new domain/machine/whatever that simply makes the correct Backend calls, aggregates and consolidates the data, and then serves it to the front-end.
It makes a lot of sense for the front-end to be able to create a single endpoint that does 4+ requests and some data manipulation rather than for front-end to wring their hands and continue making 4+ requests each time they need that specific data.
Yeah, and for a while (perhaps still?) grapqhl solved some of these issues as well. People did (do?) "schema stitching" to essentially have a BFF without really writing that much code.
Hmm. Of course it can be true in certain circumstances, but I would be surprised if on average the (compressed) size of the js bundle + subsequent JSON API request is smaller than html * the number of pages visited in a session.
Even if you are careful (and most sites are definitely not) overfetching JSON can easily happen due to API's not delivering exactly what you need etc.
Plus, in many circumstances both js bundle + json or HTML text gets dwarfed by images or other media.
reply