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.
Nope. This is kind of by design. Hasura aims to expose a very light, high-performance abstraction with self-contained access control (you can specify access control based on any relationship in the schema).
For any customisation, there are 2 options:
1) Use schema-stitching on the client-side
2) Write a graphql proxy that proxies to Hasura's graphql engine
In most cases, 2 will never be required or be fruitful, because the access control pain will keep increasing as the schema size increases!
Custom resolvers will also usually not be required because of Postgres views. Are there any specific use-cases you're thinking about?
Unfortunately, we don't have subscriptions yet. Most subscriptions implementations are not very useful because they don't handle the state initialisation or atleast-once semantics. Furthermore, add access control to subscriptions and you basically have zero performance. Firebase has a local database which is kept in sync (and handles these problems underneath) which is probably the only way of exposing this functionality "neatly" to frontend developers. Do you have any specific requirements around subscriptions? Would love to hear your inputs!
> Can I stick Hasura in front of my existing Postgres Db? Can I use my own migration tool?
We have internal tooling to make that happen on request on the paid tiers, but the experience is not smooth enough for it to be generally available as a feature yet. Currently, the best way to try out your existing schema is to `pg_dump` and `psql` into Hasura's postgres.
Yes you can use your own migrations! All you will need to do is add metadata to tell Hasura's graphQL engine to "track" whatever tables you add through your own tools. Hasura's migration tooling is inspired from rail's tooling and is essentially raw SQL. We'll be adding more docs and sample use-cases in the days to come!
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-gr...