[oefrha]

I'm aware of client side caching, but I'm talking about server-side caching. When thousands of people hit the server for the exact same updates every 30 seconds (for my scoreboard), client side caching doesn't help with anything.

I'm aware of the query plan caching mechanisms in Hasura too (I read exactly that blog post), but they don't solve the "always hits the database with every single request" issue, unlike a handwritten API endpoint / a traditional server rendered view where either the db response or the entire HTTP response could be easily cached with redis/memcached.

[xtagon]

Have a look at Materialize[0]. It automatically updates your materialized views using a dataflow model (differential dataflow) so that reads are fast even if you're running the same query over and over. It's a step up from rolling your own materialized views in Postgres or whatever, because you don't have to create triggers or anything like that, you just create views in plain SQL.

Then of course you can use a GraphQL layer above it, just like you would with any GraphQL resolvers backed by SQL, or just cut out the middleman and use plain REST instead of GraphQL.

[0]: https://materialize.io/

[gavinray]

There's nothing preventing you from setting Redis/Memcached in front of your GQL server. Apollo Server provides server-level cache strategies too I believe.

[oefrha]

Another caching layer in front of the GraphQL server could work. Apollo Server is mutually exclusive with a zero code solution like Hasura though.