2 ms·
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
by oefrha 7y ago
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.
- gavinray 7y agoThere'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 7y agoAnother caching layer in front of the GraphQL server could work. Apollo Server is mutually exclusive with a zero code solution like Hasura though.
- xtagon 7y agoHave 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/ https://materialize.io/