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?
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:
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 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.
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.
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.
put redis in front of your graphql server.
let the key be the query hash. and the ttl be 30 seconds.
if your query has many duplicate lookups (e.g. the same user appears multiple times on the leaderboard) use dataloader.
I suppose authentication & authorization would complicate things a fair bit, but yeah this should at least work for white-listed, public queries. Thanks.
Hey HN, I'm very excited to release GraphiteApps.com! My goal is to enable anyone to create apps from the worlds data, not just developers. Right now it only supports basic read-only apps, but in the future it will support full CRUD, and other datasources. Please checkout the free option - it includes 2 free apps.
We are working on the backend side creating NoCode tools for generating GraphQL APIs. If you have some time we'd love to chat! benoror [at] gmail [dot] com
Curious why you chose the name Graphite considering the well known, open source time series plotting app whose domain name is confusingly close to yours:
It sounds neat in theory, but there are no screenshots and I can't view any kind of demo without creating an account which is a non-starter so I have no idea what the actual quality is.
You have to manually edit the display for every single instance of an item, rather than just being able to set it for all items of that type? That seems tedious and error-prone.
Thanks for the feedback, I get where you're coming from. I thought a lot about this. If you set it by type, then it wouldn't make sense either. Take pokemon() and pokemon() { evolutions } for example. For pokemon() you would expect a profile like component, and for evolutions you would expect a list item component, even though they are the same type (Pokemon). That being said, reusable components is on the roadmap, this is just the beginning.
Please elaborate somewhere on the website what it is going to generate. Web application, mobile app, smart watch app(based on one of the image) or all of them or just a responsive website. Other than that I had the same suggestion to remove requirement for account creation for trial or have a video/animation of how it works.
Good point, it generates a web app! It's built with native tech so eventually native apps. I've heard that suggestion a lot, video coming soon. Thanks for the feedback!
i'm sorry but i came here earlier today and wanted to comment how there is literally zero examples or demos on the site without actually registering, however many beat me to it. so i saw that the author was going to put up a demo video and i waited. now seeing the demo video i have to say, what was i waiting for. i watched the video and there is nothing demoing how to actually build the app. all i see is a video of someone fiddling with setting for an already completed app. where are the demo showing how to easy it will be to connect your graphql service to this. where is the demo showing how to actually build a screen with data being pulled from graphql. sorry dude, but imho, you missed the mark with this. again you proved that programmers make lousy marketers.
Hey, author here. Thanks for the feedback, sorry about the lack of marketing material - I'll get better at it. Let me address some issues you brought up:
- "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.
your video has no sound, voice over or explanation _what_so_ever_. again... you built the thing, so you know what's going on. how am i, as a potential customer, suppose to know what this is and does. you can defend yourself til you're blue in the face but that doesn't make the video any more clear to a potential customer. I would suggest that you look at these other product demonstration videos for inspiration.
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.
This is sweet ! I tried plugging in a couple GraphQL endpoints and it spinned up an app right away. I've subscribed to your newsletter for future iterations. Excited to see what's to come!
Not sure if this is related, but when I enter my GraphQL endpoint and click "Create my App" I am redirected to a weirdly escaped URL with an invalid hostname.
Tailwind isn't really recognizable at all, since it doesn't ship with any components/style like Bootstrap. It is however such a pleasant way to write code, I'll never go back to regular CSS.
It does come with some default styles (https://tailwindcss.com/docs/preflight), which can be spotted to some degree. There are also some example components, that a lot of people copy, and then transfer some of those styles into other components.
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?