
Show HN: Hasura – Fast, instant GraphQL APIs on Postgres - tango12
https://github.com/hasura/graphql-engine
======
kilburn
This is very impressive. Congratulations!

What I'm not seeing is how do you envision enforcement of complex business
rules when using this API. Examples (silly, but you get the idea):

\- The price is only visible for projects of type "whatever".

\- The price may only be updated when it is not closed (closed_date is null)

\- The project is only visible on mondays

The other point I don't see is how do you expect to trigger side-actions when
changes are made. For instance:

\- Send an e-mail when a project is created

\- Call a webhook when a post is modified

Finally, and this may be from my lack of expertise with GraphQL, how do you
deal with recursive data structures? For instance, how would you store and
fetch a tree of categories?

~~~
vsurabhi
> What I'm not seeing is how do you ..

You can write fairly complex rules with the access control layer ! The first
two conditions are possible (except for the project is only visible on
Mondays).

    
    
      allow select on rows which satisfy this property: 
      { "project_type" : { "_eq" : "whatever" } }
    
      allow update on rows which satisfy this property: 
      { "closed_data" : { "_is_null" : true } }
    
    

The idea is simple, we provide a boolean expression based access control layer
which can use variables from headers. When you can't specify it using the
access control layer, you can write this in your own graphql layer and schema
stitch with hasura. So you only have to write what is not possible with the
access control layer.

> The other point I don't see is how do you ...

You can use the tooling around Postgres ! You can create an `ON INSERT`
trigger on the table and listen to these events.

We're launching something very cool in the subscriptions/event-source to solve
these kinds of problems. We also have 2 nice projects that work independent of
the graphql-engine to help with change subscription on postgres (skor[1],
pgdeltastream[2])

[1] [https://github.com/hasura/skor](https://github.com/hasura/skor) [2]
[https://github.com/hasura/pgdeltastream](https://github.com/hasura/pgdeltastream)

~~~
kilburn
> u can write fairly complex rules with the access control layer

Oh, I see. As a suggestion then, many business rules are not tied to roles.
You may want to look into some "always enforced rules" or something like that,
to avoid having to repeat these rules for each role (and the maintenance
nightmare this entails).

> your own graphql layer and schema stitch with hasura

Again, I'm not versed in GraphQL in general, so this is from my ignorance.
Maybe you could provide some example/tutorial on "stitching your own GraphQL
apis with hasura" (your other examples, posts and tutorials are awesome btw!).

> You can use the tooling around Postgres

Fair enough. I've always found a bit hard to properly manage and test these
native features (much harder than managing/testing pure code), but it is a
sound solution nonetheless. Maybe you want to hint to these other projects
somewhere in hasura's docs (I've checked them and couldn't find it, but maybe
I'm just blind/didn't look hard enough).

Again, awesome project and good answers. I can't stop going through possible
pet-projects to try this out soon! :)

~~~
praveenweb
> Maybe you could provide some example/tutorial on "stitching your own GraphQL
> apis with hasura"

We have an example of schema stitching in this repo
[https://github.com/hasura/graphql-schema-stitching-
demo](https://github.com/hasura/graphql-schema-stitching-demo)

It stitches a weather API schema and a person schema. Hope it gives an idea.

------
tango12
Hi HN! Super happy to announce the first open-source release of the Hasura
GraphQL engine.

This is a standalone service that gives you GraphQL on Postgres. It comes with
fine-grained access control that can integrate with any auth provider. It can
also work with any existing postgres database as is, and allows you to expose
select tables/views across your postgres schemas over GraphQL.

Looking forward to your feedback!

~~~
minxomat
How does this project relate to prisma?

~~~
vsurabhi
Hi, I'm one of the core contributors to the project.

Hasura and Prisma have very different approaches and end-goals at the moment.

TL;DR: Very simply put, Hasura is postgres first and adds an access-control
layer to make it possible to query from the front end directly.

The longer version:

Prisma is intended to be a GraphQL ORM to Postgres (and several other
databases with a common API) whereas Hasura is more database first and
intended to let you leverage Postgres features over GraphQL.

Hasura comes with and lets you use any postgres migration system and then
gives you GraphQL on top of it. This is what allows Hasura to give you GraphQL
over any existing Postgres database and application even.

Hasura also comes with an optional access-control layer that makes it feasible
to be used by frontend clients directly. This access control is inspired from
postgres's RLS but does not depend on or use postgres RLS and can be coupled
with application logic/auth.

~~~
filleokus
> Prisma is intended to be a GraphQL ORM to Postgres

Sorry to be hijacking this thread, but how would you say Prisma compares to
something like Graphene (with an appropriate ORM adapter). I've only used
Graphene with Python and the SQLAlchemy adapter, but it sounds pretty similar?
Is Prisma typically used as the only ORM in project, or is it used in
conjunction with some other ORM?

~~~
sorenbs
Happy to provide a more thorough answer :-)

You should think of Prisma as the data layer for your applications. If you
look at large tech companies who are typically ahead of the status quo for how
to build applications, then you see that there is a trend to move away from
traditional ORMs.

Twitter has a service called Strato that manages data access for all their
services. Facebook has TAO that serves a similar role. Prisma is an open
source implementation of that pattern.

If you are building a GraphQL API using for example Graphene, then you could
use Prisma as your data layer, but Prisma can also be used in non-GraphQL
applications. If you are using the Nodejs implementation, then you can take
advantage of schema delegation to simplify the implementation of your
resolvers. The GraphQL ecosystem is still evolving, so these capabilities will
come to more languages in the future.

So in short - Prisma replaces SQLAlchemy, not Graphene. Hope that provides
some clarity :-)

------
rcdmd
Nice work. There are several competitors in the automagic Postgres
REST/GraphQL space, and you're nailing documentation and ergonomics here. Your
site and the Hansura Console sets your project apart from the rest.

------
sheeshkebab
GraphQL is interesting although it doesn’t appear to be answer to designing
better APIs (poor modularaization, monitoring, and tooling come to mind).
“Mutations” look to be an afterthought, and schema/ui are not impressive
either.

Above plus companies tripping hard to monetize tooling around something that
you get completely for free with REST...

Even as UI engineer I don’t get the appeal of it - state, caching and all the
“performance” tuning make it too complicated.

------
mikl
First glance reaction: Awesome, just the thing I need.

Then I saw the fine print: AGPL. Haskell.

The thing might be awesome, but the combination of the legal risk from AGPL
(very little legal precedent for AGPL, especially outside the US, so the real
legal implications of the license are very murky) and maintenance risk from
Haskell (finding good Haskell developers is hard, and the learning curve is
brutal), makes it a lot harder to choose.

~~~
tango12
Hm...Haskell was an important initial choice for us because of our team's
comfort with the language and also because it's neat to implement parsers and
compilers. The Hasura engine is essentially a GraphQL to SQL compiler :)

I'm not sure I understand your point about AGPL? Do you have the same issue
with the MongoDB license and would hesitate to use Mongo because of their
AGPL? Why is this different? Just curious, would love to understand where
you're coming from!

~~~
mikl
I’m sure Haskell is great, just saying its a bit of a risk to add to your
stack if you don’t already have Haskell developers in house.

That, and the AGPL issue are both more important in this case (compared to
MongoDB), because of the position in the stack that Hasura GraphQL Engine
(HGE) would have. In the MongoDB case, we would almost always have an
application server between Mongo and the GraphQL client, where custom business
logic could be implemented, so Mongo can be treated as an external system
whose source code we do not need to modify (like PostgreSQL in the case of
HGE).

In case of HGE, the GraphQL client would talk directly to HGE, and thus any
customisation would most likely need to happen inside HGE, whether by plugins
or patches or whatnot, making it tricky to avoid having to open source your
custom business logic (as well as probably having to write it in Haskell).

~~~
tango12
Ah! That's interesting.

We didn't intend for Hasura to be something like a boilerplate that you would
modify. Mostly because it's harder to work with upstream changes when you work
with OSS software like that unless it's an explicit library type dependency.
What OSS service type component do you use (know of?) that is used in this
way?

Currently, we encourage users to use GraphQL schema stitching to customise
their GraphQL schema/resolvers treating HGE almost as an external GraphQL
service.

~~~
mikl
I see. Maybe I’m too much of a pessimist, but I imagine most products would
need custom server-side business logic, and that business logic would also
need to talk to the database. So I guess you could put your own GraphQL server
in the middle and just proxy some queries to Hasura and answer others with
your own custom code.

But if you’re already building a separate GraphQL server with database
integration, the business case for HGE is weakened, since you might as well
build the same logic in the other system.

------
mmanfrin
I have a bit of a dumb question: where does GraphQL fit in a stack? I've seen
in used primarily as a means of aggregating a bunch of disparate
microservices, but then I see things like this that put it in the role of app
server, almost. What advantages does this give over, for example, a Rails API
(also on Postgres)? If it is supposed to fill the role of app server, how do
you handle things more involved than simple CRUD operations? Like, if I sign
up a user, how -- in a GraphQL world -- would I send a welcome email,
typically?

~~~
FooBarWidget
I see GraphQL as a _protocol_ replacement for REST. With REST you have the
following problems:

* Responses either contain more data than you need, or not enough data (e.g. you need data for related entities as well).

* With REST, if you need data for related entities then you need to perform additional REST calls, resulting in more network roundtrips.

With GraphQL you can specify exactly what you want, and the server responds
with just that, in a single call.

~~~
yashap
We’re experimenting with it on a new product at my company, and this is how we
use it. Specifically, we use it as an API gateway in front of a bunch of
restful services.

Another benefit is a more robust type system than you get with JSON. GraphQL
supports union types, interfaces, etc., allows you to provide more strongly
typed contracts between the backend and frontend.

One downside though - while the responses can become smaller, with fewer round
trips, the requests get A LOT bigger (than with REST), as you have to specify
every field, subfield, etc. This is especially true if you make heavy use of
union types - then you have to specify all the fields, sub fields, etc. of all
the various concrete members you might get back. Like requests with payloads
over 1KB is not uncommon. If you’re polling, and the result of the polling is
generally an empty response, you may end up sending significantly MORE data
over the wire, not less.

~~~
slitchfield
If you're sending large requests polling for an empty response most of the
time, that might be a good use case for a custom directive.

------
michaelmcmillan
I am very hesitant to couple the business logic of any application to the
transport layer (GraphQL) or the persistence layer (Postgres) for that matter.

~~~
M_Bakhtiari
If you're not going to couple any business logic to the persistence layer,
then what the hell is the point of using a RDBMS?

~~~
michaelmcmillan
Your reply suggests you either couple everything or nothing. It’s more nuanced
than that. Everything is a trade off. With that said, it looks like this
library will position itself in the center of your architecture — and I would
be very _hesitant_ to do that.

~~~
M_Bakhtiari
Of course anyone should be hesitant to over-model the business domain in any
part of the application including the database, but the entire reason of
existence of the RDBMS is to maintain consistency with _something_ , and if
that something isn't the business domain, then what good does it do?

~~~
michaelmcmillan
I don't know where over-modeling fits in the argument. Business logic in an
isolated part of an application is likely to age better than something that is
intertwined with a database or other external dependencies.

------
benoror
Impressive! How's it different from postgraphql
([https://postgraphql.github.io/](https://postgraphql.github.io/)) or
postgraphile
([https://www.graphile.org/postgraphile/](https://www.graphile.org/postgraphile/))?

~~~
tango12
Broadly similar projects! The emphasis of Hasura is to make it seamless to
work with existing databases.

The primary difference is how authorization is handled. In Postgraphile, you
map your application roles to Postgres users and define policies using
Postgres's RLS. With Hasura, you define rules on roles (similar to Postgres's
RLS) but it integrates into your existing auth system using webhooks.

Also, peripherally, we have quite a bit of tooling with an admin UI and a
rails-like migration system to make the dev workflows easier :)

~~~
mathnmusic
> The emphasis of Hasura is to make it seamless to work with existing
> databases.

Yet, I spent 15 minutes searching for example of using Hasura with an existing
schema. Your "Getting Started" page has two examples: Deploy on Heroku and Run
with Docker - in both cases, using a fresh database, not an existing one.

~~~
tango12
Bugger! Sorry for the inconvenience. We're updating the docs now to make this
easier to navigate too.

EDIT: Docs updated, we'll keep improving it too :)

~~~
mathnmusic
Can you share the link? This page still refers to new database:
[https://docs.hasura.io/1.0/graphql/manual/getting-
started/in...](https://docs.hasura.io/1.0/graphql/manual/getting-
started/index.html)

Homepage has the GitLab example, but not actual "Getting Started" page.

~~~
tango12
For Heroku:
[https://docs.hasura.io/1.0/graphql/manual/deployment/heroku/...](https://docs.hasura.io/1.0/graphql/manual/deployment/heroku/using-
existing-heroku-database.html)

For Docker:
[https://docs.hasura.io/1.0/graphql/manual/deployment/docker/...](https://docs.hasura.io/1.0/graphql/manual/deployment/docker/index.html)

------
tango12
Oops! GitHub is down :(

We're on [https://hasura.io](https://hasura.io) too.

~~~
SOLAR_FIELDS
Huh, I just tried it and Github is up (making this post 2 minutes after the
parent). Located in EU if that makes a difference.

------
SOLAR_FIELDS
As a newbie to GraphQL who is having some growing pains adopting a UI for a
data warehouse that was basically bolted onto a REST API designed for backend
queries, can someone help me understand what the pros and cons are for
something like this vs hand rolling all of the backend GraphQL stuff yourself?
We have been evaluating switching/offering a GraphQL backend for our UI to
consume for our product since it seems well suited to our use case but so far
the effort required has outweighed the gain we would get from it. Because of
this a somewhat turnkey solution like above might be more appealing.

~~~
tango12
I think it depends on how much business logic you have in your REST API layer.
If you can get away with using a turnkey solution like hasura with the right
access control rules or by adding schema stitching then it would save a lot of
effort.

I think the best thing would be to try a turnkey solution for your
appliaction's database and then evaluating the effort saved. Turnkey solutions
also might end up partial effort if not all. For example, Hasura is a great
fit for incrementally adding read-only GraphQL queries which is where a lot of
benefit of GraphQL for the UI lies.

------
garindra
We at Sale Stock (fashion e-commerce in Indonesia) built an in-house system
similar to this but more automatic and works with CockroachDB. Not open source
yet, but might be interesting to you guys:
[https://speakerdeck.com/salestock/laskar-high-velocity-
graph...](https://speakerdeck.com/salestock/laskar-high-velocity-graphql-and-
lambda-based-software-development-model) (skip to around mid-way, first half
is intro to GraphQL)

~~~
uptime
Interesting. Does this mean you plan to release it?

------
victor106
Great job!!! Looks awesome

I see that one of the ways you want to monetize this is by offering support.
Providing support is a good approach to monetize an open source project but
it’s not very scalable. Have you thought of any other ways you can monetize
this?

If others in the HN community can pitch in with any ideas they have on how to
monetize an open source project that would be great as well.

------
HugoDaniel
Really cool! Congrats.

It would be awesome if it could be made compatible with Postgraphile
([https://www.graphile.org/postgraphile/introduction/](https://www.graphile.org/postgraphile/introduction/))

------
zapita
This is exactly what I was looking for. I will give it a try on my next
project.

~~~
alberteinstein
Please do reach out to us on discord [1] if you have any questions whatsoever
:)

[1]: [https://discord.gg/vBPpJkS](https://discord.gg/vBPpJkS)

------
spocklivelong
I work with a Django app on Postgres, and I'm not sure how I would migrate
that to GraphQL. How things play out in terms of django specific tables? What
about relationships between tables? We mostly use the Django app to expose
REST APIs, which deal with making complex queries using QuerySets to Postgres.
Moving this to GraphQL mean that all the business logic that sits on the REST
APIs need to be moved to the frontend?

~~~
tango12
Well it depends on your app. Technically, you have to rebuild your app to
speak GraphQL to the frontend instead of REST. Internally, your GraphQL
resolvers (like URL handlers) would then do similar work with using QuerySets
as you're doing now.

If you'd like to leverage Hasura, it would be a good fit to potentially
replace the "read" portions of your app with GraphQL quite easily. And then
eventually you would have to move to writing a GraphQL gateway to handle some
of the transactional logic and delegate the other stuff to Hasura via schema-
stitching.

------
uptime
Thank you for releasing this. I am impressed with Hasura! No knock on
postgraphile, I am trying that out too as well as prisma, but this looks very
well done and the boundaries are clear (like postgraphile, views are important
to make things work). Your UI is going to make people happy.

I have two questions: 1. can I point the hasura cli at my local install? and
2. Can we have UUID fields? I'd like to use them as primary keys.

~~~
tango12
Yes and yes. 1\.
[https://docs.hasura.io/1.0/graphql/manual/migrations/enable-...](https://docs.hasura.io/1.0/graphql/manual/migrations/enable-
migrations.html)

2\. For UUID just do what you would normally do. We don’t have it on the
column drop down but you can create the table via the run_sql window with the
right type and default value, if you’re generating the UUID server-side

------
wjonas
I have been playing around with it. It's great.

Better support for ENUMS and MANY TO MANY relationships would be very needed
though.

~~~
tango12
Thanks :)

We're adding docs for enums as we speak. What did you find lacking around the
many-to-many?

~~~
wjonas
For 2 reasons inserting is tricky and querying is not super intuitive.

Example: I have 3 tables pages, page_blocks, and blocks.

\- Inserting blocks into a page is tough.

\- To query it's not very intuitive I would like to do.

pages {

    
    
      blocks {
    
        id
    
      }
    

}

& not

pages {

    
    
      page_blocks {
    
        blocks {
    
          id
        }
    
      }
    
    }

~~~
tango12
Got it! Thanks for the note, and we should be able to make this better very
soon.

------
no-such-address
This is a good trend. Will we see more work aimed at separating the data model
and human interface (to make programming with attributed graphs safe and
convenient) from back end issues (how to store data and process queries
efficiently, where traditional databases are already very advanced.)

------
jxub
Almost a third of the codebase is written in Haskell, that's really nice to
hear ;)

~~~
alberteinstein
The GraphQL Engine is written in Haskell, the Console in JavaScript and the
CLI in Go. The repo contains all the three components. :) (I am one of the
maintainers)

------
jarym
Great to see another project at this problem! We've been internally building
something very similar but it uses Kotlin (Java) instead of Haskell.

------
miga
Why does hasura.io block residential network providers in Poland? I need to
use VPN to just check the docs. That does not bode well for users.

~~~
mydigitalself
I wouldn’t imagine that to be intentional, possibly upstream infrastructure is
blocking somewhere.

------
faitswulff
How does it handle batch execution of queries?

~~~
vsurabhi
We do not batch queries. We take a slightly different approach. We convert the
GraphQL query AST into a single SQL query (no matter how nested the GraphQL
query is).

------
reilly3000
This is going to get tested today for a project. Thanks!

~~~
tango12
So cool! Please do reach out to us on discord [1] if you have any questions
whatsoever :)

1: [https://discord.gg/vBPpJkS](https://discord.gg/vBPpJkS)

------
machbio
there is mention of GraphQL proxy - any idea about any available proxies for
GraphQL at this moment ?

------
antigirl
Any subscription support?

~~~
tango12
It's in an early preview right now, and we should have something in a week or
two! Just going through some performance and security checks over the next few
days.

Do feel free reach out to us via discord if you'd like to take it for a spin.

------
jamhan
"Fast, instant"? That's, err, just dumb. Fast perhaps. Instant, never.

------
Alex3917
GraphQL is basically the new Mongo, so of course someone will try doing it in
Postgres.

~~~
dberg
Heh i kind of agree here. Reasonable docs , easy to bootstrap and completely
unaware of the underlying performance probs you are about to create bc it
“just works”. Curious to your reasons though ?

~~~
Alex3917
It’s seemingly a complete nightmare from a security and architecture
perspective. And front end devs and bootcamps love it.

I’ve never used it so my opinion isn’t fully baked, but every time I look at
the docs I’m just like wtf.

~~~
tango12
Apparently the facebook team (and others in production I'm guessing) addresses
some of this by only having a whitelisted set of queries in production. So you
get the GraphQL flexibility during development, but a effectively a static set
of APIs in production.

