Best practices for caching hasura responses in redis?

[Aditya94A]

I was wondering whether there are any officially recommended patterns for caching hasura responses to a redis instance.

Couldn't find any documentation/open issues/blog posts talking about this, here's what I have in mind:

1. Run a core server (for caching, auth) alongside hasura as a microservice
2. Add a middleware to intercept any graphql requests
3. Check if the exact request exists in redis, if so return (or whatever caching logic)
4. Otherwise, ask hasura microservice to generate a new response, cache that and then send to client

[Aditya94A]

Crazy feature idea for hasura: Let users set redis/cluster endpoints within hasura and allow users to specify caching behavior for given tables/relationships/queries => Boom. Automatic caching 🤯

[FickleLife]

Just wondering if there is any guidance for caching for Hasura? In my particular use case, I have a remote schema that runs business logic on an Apollo GQL server running on serverless. Ideally I’d like Hasura to check Redis for the cached version and if there’s a hit, skip the call to the remote schema and return the Redis data.

At the moment, what I am planning to do is have Redis with Apollo (maybe I’ll use Apollo’s inbuilt caching- will test it out) so the serverless function will have to execute but should only run for a fraction of the time it would otherwise as a cache hit will be the result 99% of the time.

As @AdityaAnand1 says above, it would be great to have Hasura manage the caching with Redis or some other method.

[Aditya94A]

Any thoughts on whether this could be picked up soon?

@rikinsk @shahidhk @rakeshkky

[yevyevyev]

A managed caching system on top of hasura would be a total killer! I see custom invalidation rules with built in triggers

[jukbot]

Unfortunately that this feature is available only on Hasura Cloud. :/ Hope that open source version still able to attach caching middleware or gateway.

https://hasura.io/docs/1.0/graphql/cloud/response-caching.html

[FickleLife]

@jukbot According to https://hasura.io/docs/1.0/graphql/cloud/response-caching.html there's a few gotchas there, namely

1. The query does not make use of remote schemas or remote joins
2. The query and any related user permissions do not make use of session variables

I use both points heavily so I am not sure I'll get any benefit out of Hasura Clouds caching vs the free version. I hope over time these are supported as I would probably head to Hasura Cloud if so (but ideally they are in the open source version too).

[tabeth]

@FickleLife

I just happened to stumble upon this - if you don't want to wait for this to be implemented, you can use a middleware proxy to serve as a cache.

See kong and tyk implementations. It's also relatively straightforward to implement yourself (see HTTP Redis as an example).

[boosh]

This plus the opaque pricing for the hosted enterprise version kills my interest in this product

[mapsgeek]

@boosh it literally just did for me too

[johnoldham33]

agree with @boosh and @mapsgeek, this cloud only feature kills hasura as an option for me. Needs to allow this self hosted as well

[rasheedk]

Try akamai caching before it reaches to hazura. It is capable of caching as json based on request headers and params and u can define rules when to invalidate. CP codes works for clearing caches on demand via any webhook.

[rasheedk]

Or try thier enterprise edition - which has caching inbulit / hasura cloud