
Show HN: Hasura: High performance GraphQL on Postgres - ecthiender
https://hasura.io/graphql
======
ecthiender
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-
gr...](https://blog.hasura.io/architecture-of-a-high-performance-graphql-to-
sql-server-58d9944b8a87)

~~~
cpursley
This is neat!

Is there an equivalent of graph.cool's hooks, subscriptions and resolvers?

Can I stick Hasura in front of my existing Postgres Db? Can I use my own
migration tool?

~~~
tango12
> Can you add hooks/resolvers?

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!

~~~
cpursley
> Custom resolvers will also usually not be required because of Postgres
> views.

Ok, that's probably a nice solution. I'd much rather write that logic in SQL
than JavaScript.

As for callback type things (sending emails, data transformations, webhooks to
3rd party services, I guess there's always pg_notify :)

> Do you have any specific requirements around subscriptions?

Mainly, pubsub with web clients would be nice.

> Hasura's migration tooling is inspired from rail's tooling

Fantastic!

------
fiatjaf
Whoa, there is too much going on here, I don't even know how to start. Is this
like Heroku, but with the database built-in?

[EDIT]: I had previously written "Postgres" instead of "Heroku" above.

~~~
tango12
This is a quick intro to the architecture. [https://blog.hasura.io/how-hasura-
works-in-doodles-ba03d6ce6...](https://blog.hasura.io/how-hasura-works-in-
doodles-ba03d6ce6044)

Ah! I was super confused when I read Postgres.

