If you know your queries at compile time, then you can register each query with the server when you build as the hash of the query. Then clients only have to send up the hash and the server can look them up in its registry; plus you now have an easy way to cache (cache based on query hash plus user). If it's the first time you've seen a query, you can hash it and add it to the registry as well.

See: https://github.com/apollographql/apollo-link-persisted-queri... https://blog.apollographql.com/improve-graphql-performance-w...

I know about apollo caching, but it's strictly inferior to HTTP caching which has tons of options (Vary, Etag, etc)

Caching per user is still going to mean tons of cache misses. Caching based on the query hash means you're going to cache subsets of the same data over and over as separate entries.

With resources over HTTP, you can separate the user specific part from the generic resource part and cache accordingly.

Plus, I like the option of caching somewhere else than the app server, like a distributed Varnish.

I'm not saying you can't cache with graphQL, it's just less natural and mature.

In practice, caching is non-trivial to implement for any sufficiently complex system even with REST. It depends on your use case of course, and how tolerant you are of stale data, but I have worked on very few frontends where HTTP caching is sufficient.