The Hasura team writes about their GraphQL engine for Postgres, plus Kubernetes tooling comparisons and database topics.
Hasura staff answer questions about its query optimization and remote joins, and a commenter found its Kubernetes tool comparisons useful for weighing Skaffold and Draft.
> The equivalent would be spot instances on AWS.
They're equivalent in the sense that you have nodes that can die anytime, but it's much more complicated. You could technically have a much lower cost on AWS by aggressively bidding low but we've had a few instances where the node only lived a few minutes.
Preemptibles nodes are max 24h, and from our stats, they really live around that amount of time. I think the lowest we've had was a node dying after 22h.
You also save out of the box because they apply discount when your instance is running for a certain number of hours.
You can even have more discount by agreeing to a committed use which you pay per month instead of one-shot unlike AWS.
I'm going to add a few more reasons to the above reply:
- UI and CLI is so much better in GCP
I don't have to switch between 20 regions to see my instances/resources. From one screen, I can see them all and filter however I like.
- GCP encourage creating different projects and apply same billing.
It's doable in AWS too, of course, but coupled with the fact that you have different projects and regions, and you can't see all instances of a project at once, this makes a super bad experience
- Networks are so much better in GCP
Out of the box, your regions are connected and have their own CIDR. Doing that in AWS is complicated.
- BigQuery integration is really good
A lot of logs and analytics can be exported to BigQuery, such as billings, or storage access. Coupled with Data Studio…
Think of Hasura as a layer in between your front-end application and your Postgres database. You would have needed infra to deploy your custom GraphQL server which you can replace using Hasura which gives you CRUD operations on your database with role based access control as explained here https://docs.hasura.io/1.0/graphql/manual/auth/index.html.
Hasura doesn't make any presumptions about data caching as that is highly dependant on the app requirements. It simply tries to run the most optimal SQL query on the database whenever any data is requested as showcased here https://blog.hasura.io/architecture-of-a-high-performance-graphql-to-sql-server-58d9944b8a87
Hasura is horizontally scalable as it is inherently stateless. Each Hasura GraphQL engine instance runs independentally against the underylying database it is connected with.
For replicating the Hasura GraphQL schema across environments Hasura uses its Rails like migrations tooling as explained at https://docs.hasura.io/1.0/graphql/manual/migrations/index.html.
PS: I am part of the Hasura team
Hi HN. I’m from the Hasura team.
When we first started writing the data APIs, GraphQL had just come out and was pretty rough around the edges.
We love how the tooling and community around GraphQL have matured over time and today we are very excited about announcing GraphQL on HN.
The idea is that you create tables on Postgres, define permissions and
they can be automatically queried and manipulated over a GraphQL interface from
front-end applications.
We have taken great care to make these APIs as efficient as possible. In fact, the low memory footprint and negligible latency when
compared to querying postgres directly, you could even replace the ORM with GraphQL APIs for most use-cases on your server-side code.
Read more here: https://blog.hasura.io/architecture-of-a-high-performance-graphql-to-sql-server-58d9944b8a87
Answering a few points:
Hasura allows you to turn any "query" to a subscription, essentially live queries.
Hasura's query optimization is actually one of the core features. Hasura is structured as a transpiler that converts GraphQL, adds access control clauses and then renders a single SQL for the database. Very different from a typical ORM approach or the dataloader approach.
More details: https://blog.hasura.io/architecture-of-a-high-performance-graphql-to-sql-server-58d9944b8a87
I would recommend pre-building html markup as much as possible for performance boost and hydrate on the client for dynamic content, instead of going the SSR route. Obviously this may not be applicable for all use cases though.
Shameless plug: I just wrote a guide to approach dynamic content on static sites a few days ago.
https://blog.hasura.io/approaches-to-add-dynamic-content-statically-generated-sites-jamstack/
At Hasura, we recently released the preview of Remote Joins that allows you to join different GraphQL APIs. So, all you need is a graphql wrapper over your DB/sources (Postgres comes in-built) and you can then join whatever sources.
https://blog.hasura.io/remote-joins-a-graphql-api-to-join-database-and-other-data-sources/