Isn’t every graphql a post, so no http response caching, so you need to do it in-app or with redis?
N+1 and nested queries etc were still problems last I checked (few years ago).
I’m sure there are solutions. Just that it’s not as trivial as “use graphql” and your problems are solved.
Please correct me if I’m wrong
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... 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... or maybe a more popular flavor using prisma: 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.