Keep in mind that you can do graphql queries via GET. If the are just requesting data you can do ?query={hello { world } }&variables=.

@kieraneglin I’m not doing this myself, but as I understand it folks like Facebook who are doing this at scale use persisted queries such that the front end is doing query=$hash&variables=, and then you only need to worry about the variables fitting within the GET request limits, which normally should be fine.

Definitely interested to see what your automatic persisted queries solution looks like. Absinthe has a behaviour for doing persisted documents, although I think the built in backend for that is only related to queries known at compile time. Nonetheless, it’s a behaviour, so you could absolutely make one that was more dynamic.

As @NobbZ said, GraphQL is not ideal when it comes to caching, especially not with HTTP caching.

A CDN would have to cache POST requests (already a no-go in HTTP, as they are meant for side effects). Also, the benefit of caching the whole query would be limited, as the clients could make slight changes to the query, or request fresh data alongside the cached one, and the whole query will be a cache miss.

There are some approaches to caching partial results server-side, but nothing coming close to the well-established and simple HTTP caching, used by CDNs.

I personally like the flexibility and control over data that GraphQL gives to the client, but when caching is important I use REST. For example, we have REST endpoints for a few high-traffic, cacheable resources, alongside the GraphQL API that serves most of the other needs of the client.

One other possibility worth mentioning is to have a GraphQL API on top of REST endpoints. The GraphQL API would act as the client for the REST endpoint, and would have to take care of caching using HTTP headers.