CDN caching with Absinthe

POST is generally considered uncachable, as you do them for side effects.

Fair enough! In that case, what’s the common solution for caching gql responses?

Not using GraphQL.

Cachability is the big downside of GraphQL. Similar discussion as with SOAP apply.

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.

That’s too bad! Thank you all for the information.

This seems like a problem that many people would benefit from being solved. I might try my hand at something similar to Apollo where the query is hashed and this hash is sent via a REST get request. If Phoenix is aware of this hash and has the result cached, it returns the cached data with appropriate headers so that CDNs can work with it. If Phoenix doesn’t have this result cached, a second gql request is made that ends up caching the result for the next people that try within the TTL.

The added complexity is less than ideal, but I imagine that it would solve our use case

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

Since you’re a bit of an authority on this, I should ask. I’ve read that GET requests are avoided because the payload can be too long for URLs to handle. Is this a legitimate concern or is this information outdated? Because if I can just use GET requests, that’d make life a lot easier.

In other news, I have a proof of concept for Automatic Persisted Queries with customizable cache control headers with Absinthe. I’ll also be playing around with that to see how it feels!

@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.

Apollo seems to have found a nice way how to accomplish server-side caching of GQL queries, even using CDN: Server-Side Caching - Apollo GraphQL Docs .

Not supported by Absinthe yet unfortunately.

The apollo solution is based on directives and middleware, both of which Absinthe has. If someone wants to take a crack at this I’m sure it’d make for a great library, and I’d be happy to make any tweaks to Absinthe that are needed if they run into blockers.