A tangentially related question about these codeless GraphQL API/app generators while we're on this topic. I'd appreciate opnions on this one.

A while back I was building a read-heavy site where the most popular views are easily cachable -- think a scoreboard monitored by hundreds or thousands of people simultaneously, and updated every 30 seconds. The view, or data for the view should obviously be cached, so that thousands of people don't need to hit the database at the same time with the same query.

I looked into whether I could leverage Hasura for this (no particular reason, just heard raving reviews and wanted to give it a shot). Turns out Hasura always hits the database with every single request, and it seems there's no way to avoid this. Of course GraphQL doesn't lend itself well to caching either.

Are there any solutions to this sort of problem? Or was my use case fundamentally not suitable for Hasura or similar tools?

In large part, caching in GraphQL stems from client-side tools like Apollo or Relay, which have a fairly sophisticated cache ability.

https://www.apollographql.com/docs/react/caching/cache-confi...

https://relay.dev/docs/en/network-layer#caching

You can also implement things like Dataloader to batch/cache your requests:

https://github.com/graphql/dataloader

Hasura in particular implements two forms of caching. While not directly data-related, it does cache both the GraphQL query-plan and SQL query-plan with prepared statements:

https://hasura.io/blog/fast-graphql-execution-with-query-cac...

Hasura's architecture ensures that 2 "caches" are automatically hit so that performance is high:

GraphQL query plans get cached at Hasura: This means that the code for SQL generation, adding authorization rules etc doesn't need to run repeatedly.

SQL query plans get cached by Postgres with prepared statements: Given a SQL query, Postgres needs to parse, validate and plan it's own execution for actually fetching data. A prepared statement executes significantly faster, because the entire execution plan is already "prepared" and cached!

So cache on the client-layer, with cache on the server layer, especially if you implement something like Relay which has the ability to fetch only individual fragments, leads to pretty tiny and performant queries.