Show HN: Create apps from GraphQL APIs without writing code
graphiteapps.com
graphiteapps.com
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?
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.
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.
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.
Edit: without signing up* and who wants to sign up to the unknown!?
- "all i see is a video of someone fiddling with setting for an already completed app."
The demo isn't starting with an "already completed app". Graphite generates a default app based on your GraphQL schema, and it is up to the user to further customize it to their needs. That's why it looks "already completed".
- "where are the demo showing how to easy it will be to connect your graphql service to this."
Connecting to the GraphQL services was shown in the beginning of the demo video when I typed in the GraphQL URL.
- "where is the demo showing how to actually build a screen with data being pulled from graphql"
Every screen in the demo video showed data being pulled from GraphQL. Graphite generates the queries behind the scenes automatically without the user even knowing.
https://blog.hubspot.com/marketing/demo-video
i'm not trying to be a jerk. you have most likely put an incredible amount of time and energy into bringing this product to life. don't let it fail because you refuse to take another day and demonstrate it properly.