it used to be the case that graphql requests are in POST, but not anymore: https://nearform.com/open-source/urql/docs/api/core/#:~:text=cache%2Dfirst.-,preferGe

it used to be the case that graphql requests are in POST, but not anymore: https://nearform.com/open-source/urql/docs/api/core/#:~:text=cache%2Dfirst.-,preferGetMethod,-%3Fboolean%20%7C%20%27force%27%20%7C%20%27within https://nearform.com/open-source/urql/docs/api/core/#:~:text... example for urql on top of http level caching, you can do any type of caching (redis / fs / etc) just like a regular rest but at a granular level, for ex: user {comments(threadId: abc, page: 1, limit: 20) { body, postedAt} is requested and then cached, another request can come in thread(id: abc) {comments(page: 1, limit: 20) {body, postedAt} you can share the cache. N+1 is solved by a tighter integration with the database, for ex: https://www.graphile.org/postgraphile/performance/#how-is-it-so-fast https://www.graphile.org/postgraphile/performance/#how-is-it... or maybe a more popular flavor using prisma: https://pothos-graphql.dev/docs/plugins/prisma/relations#:~:text=%7D)%3B-,t.relation,-defines%20a%20field https://pothos-graphql.dev/docs/plugins/prisma/relations#:~:... but of course, there is always the classic dataloader as well. I am not saying that use graphql and all the problems will be solved, but i am saying that the problem that OP proposed has been solved in an arguably "better" way, as it does not tie the presentation (HTML) with the data for cases of multiplatform apps like web, or native apps.