We’re looking at Phoenix with Absinthe to replace a very high traffic route of a Rails application. We’ve created a proof of concept app that’s performing very well, but it’s been difficult to find documentation on real-world caching for Absinthe.
We use Cloudfront and cannot change this to use a different CDN. We are using POST requests from our Apollo client. We’d like to cache at the CDN level, but we can’t find much information on setting cache control headers per-query. Is there a built in way to approach this? If not, I was thinking of writing a middleware that sends a cache control header per-query name or hash, but I don’t want to do that if there’s an out of box solution.
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
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.
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.
@benwilson512
Hi this seems straight forward and interesting! I would like to attempt if it hasn’t been implemented since then (looks like so in the absinthe git repo).
