
Hasura raises $9.9M to simplify GraphQL - pritambarhate
https://techcrunch.com/2020/02/26/hasura-raises-9-9m-series-a-to-simplify-graphql-for-developers/
======
elitan
This is fantastic to see. First time I tried out Hasura back in late 2018 I
was AMAZED.

After going through multiple different stacks such as MeteorJS, Firebase,
building my own REST/GraphQL API etc. Nothing really felt right.

That was until I found out about Hasura.

I actually had to assemble a quick meetup at the co-working space I was on
(true story) to show everybody this software. Hasura Tweet:
[https://twitter.com/HasuraHQ/status/1068145251267895300?s=20](https://twitter.com/HasuraHQ/status/1068145251267895300?s=20)

They were all amazed and many use Hasura in production today in their apps.

For myself, I was so enthusiastic about Hasura and I always had Google
Firebase in the back of my mind. Google Firebases DX is really good. I really
liked it. But I did not like their tech (noSQ / REST / vendor lock-in).

So, I decided to start [https://nhost.io](https://nhost.io).

Nhost is like Google Firebase but with PostgreSQL and Hasura (GraphQL). Right
now providing database, API, auth and storage. Here is a short demo:
[https://www.youtube.com/watch?v=MWB5RXzlJM8](https://www.youtube.com/watch?v=MWB5RXzlJM8)

I feel very fortunate to be able to work with such awesome open source
software and the success of Hasura makes me so happy, because they are, as
mentioned in the comments field before me, a game-changer!

~~~
samblr
Just tried hasura, it is amazing to get all crud graphql apis out of box.

How do we add business logic ?

Folks @hasura, where do we learn about haskell ? any helpful pointers much
appreciated.

~~~
dvasdekis
I'm running a full production algorithmic trading platform, and our frontend
interactions are handled by Hasura. For me, the appeal was in writing all the
business logic as Postgresql triggers, which (provided they're written as true
SQL and not plpgsql), scale beautifully with load. Hasura has a real appeal
when you're keen to do your important logic in SQL.

Check out the result here:
[http://www.hedgecheap.com](http://www.hedgecheap.com)

------
awb
Some major players in the "GraphQL in a box" space:

[https://www.graphile.org/postgraphile/](https://www.graphile.org/postgraphile/)

[https://hasura.io/](https://hasura.io/)

[https://www.prisma.io/](https://www.prisma.io/)

There are plenty of "REST API in a box" solutions as well:

[https://github.com/PostgREST/postgrest](https://github.com/PostgREST/postgrest)

[https://github.com/prest/prest](https://github.com/prest/prest)

[https://resthapi.com/](https://resthapi.com/)

~~~
markhalonen
I ultimately chose Postgraphile over Hasura. Mostly because the Postgraphile
codebase seemed way hackable, written in TS/JS with a plugin architecture.
I've tried some Haskell and that's just a whole nother world I don't have time
to learn. So far it's working great for me.

~~~
vosper
FWIW, I went the other way, mostly because I found the GraphQL queries that I
wrote in Hasura to be much nicer to read than the equivalents that I got with
Postgraphile.

~~~
rattray
Interesting; can you provide an example? Sounds like a nice way to compare
various approaches to GQL queries, and general best-practices...

------
cpursley
Hasura is a game-changer. I'm never writing CRUD backend apps again by hand.

Combine Hasura (automatic GraphQL on top of PostgreSQL) with React Admin (low
code CRUD apps) and you can build an entire back office admin suite or form
app (API endpoints and admin front end) in a matter of hours.

This adaptor connects react-admin with Hasura: [https://github.com/Steams/ra-
data-hasura-graphql](https://github.com/Steams/ra-data-hasura-graphql)

Here's a reference application I put together:
[https://github.com/cpursley/react-admin-low-
code](https://github.com/cpursley/react-admin-low-code)

~~~
jonatron
Django has had an automatic admin site since 2006 or earlier, this isn't a
game changer for me.

~~~
michelpp
These aren't the same things. Hasura is not an admin interface, although it
provides something like one. It's an application API.

The django admin interface is not usable by a frontend as an application API.

Django requires you to "meta-model" you have to write Python classes that map
to your tables, this is usually duplicate work.

Django's ORM must support many databases, so it produces "least common
denominator" SQL and is (stock) oblivious to Postgres' many enhanced data
features, you are forced to use various community sourced extensions to get
access to features that have been in postgres now for many years.

Django's security system is django only. You are forced to go through django
for access control across your business. Eventually this abstraction leaks,
and someone starts logging into the db from some other framework and now you
have two problems.

This is my opinion and I'm sure I'll get downvoted for it, but Django, Rails,
Node, all the Java frameworks, all the meta-modeling and NIH syndroming, are
all utterly obsolete. Everything they do can be done in 99% SQL by a data
scientist with the help of a competent DBA. "Web application programming" is
going to go the way of the dodo bird and devs who don't start learning higher
level skills like complex SQL, statistical modeling, linear algebra, and to
either be a competent DBA or learn how to treat them fairly with be the first
batch of programmers "automated out of a job" by tools like Hasura.

~~~
RussianCow
> Django requires you to "meta-model" you have to write Python classes that
> map to your tables, this is usually duplicate work.

You don't have to duplicate any work because you don't actually have to write
any raw SQL, since it all gets translated by Django. So yes, there's an extra
layer of abstraction there, but no duplication on the developer's part.

> Django's ORM must support many databases, so it produces "least common
> denominator" SQL and is (stock) oblivious to Postgres' many enhanced data
> features, you are forced to use various community sourced extensions to get
> access to features that have been in postgres now for many years.

Practically every Django release adds support for more and more database-
specific features out of the box, to the point where I don't remember the last
time I had to use a third-party library to take advantage of a PostgreSQL
feature. But even if you do, so what? It's no different than using a Postgres
extension.

The HUGE advantage that ORMs like Django, Rails, etc have over writing raw SQL
is their composability. Django provides lots of tools that make it VERY easy
to reuse code relating to models and querysets, whereas SQL is notoriously
difficult to keep DRY. And this issue gets significantly worse when you start
to pull in data that lives outside of the DB.

On top of that, there is the more obvious issue that good DBAs are rare and
expensive compared to Python/Ruby/whatever engineers.

> Django's security system is django only. You are forced to go through django
> for access control across your business. Eventually this abstraction leaks,
> and someone starts logging into the db from some other framework and now you
> have two problems.

I do completely agree with this, and I think it's Django's weakest point by
far. But you can always forego the ORM's integrity/trigger features and add
those at the database level in your migrations.

> This is my opinion and I'm sure I'll get downvoted for it, but Django,
> Rails, Node, all the Java frameworks, all the meta-modeling and NIH
> syndroming, are all utterly obsolete.

Hasura and related projects are really great, don't get me wrong, but this is
outright FUD. There are pros and cons to both approaches, and to claim that
one is "utterly obsolete" is nonsense. There are lots of situations in which
turning the database into your API just doesn't make sense.

~~~
michelpp
> You don't have to duplicate any work because you don't actually have to
> write any raw SQL, since it all gets translated by Django. So yes, there's
> an extra layer of abstraction there, but no duplication on the developer's
> part.

There is still some duplication of effort, for example when you change the
model, yes django will create the migration script for you, but you always
have to verify it and often change it especially when you're merging branches.
And since the migrator only supports a subset of postgres' DDL abilities, even
simple things like renaming objects, or applying advanced indexing techniques
you often have to write hand sql migrations anyway, which require you knowing
sql, so why not just do all in sql?

> Hasura and related projects are really great, don't get me wrong, but this
> is outright FUD. There are pros and cons to both approaches, and to claim
> that one is "utterly obsolete" is nonsense. There are lots of situations in
> which turning the database into your API just doesn't make sense.

It was a strong statement of an unpopular opinion, but FUD is a fundamentally
dishonest statement, and I did clearly prefix my statement with "This is my
opinion and I'm sure I'll get downvoted for it". As someone who knows my
opinions well you know I honestly believe it. But that's ok I appreciate you
keeping me on my toes when the coffee gets me in an agitated state!

That being said, I still do believe it. I do pick on Django pretty hard, but I
feel the same way about many of the Python frameworks to a certain degree and
the "web application framework" pattern in general. Django is just the one I
have seen the most bloviated circumlocution of code to do simple tasks with,
and often when I have run into problems with Django, it was usually Django's
fault (ahem, autocommit) not the developers. It's a classic foot gun.

A recent example I have had to boggle at, a half dozen AppEngine
microservices, cross calling each other with http RPC all autocommiting to 3
different postgres databases with less than 100k rows of data total. The
microservices were entirely responsible for maintaining referential integrity
entirely defeating the point of using postgres in the first place.

The whole thing could have been a set of simple functions, much of the heavy
lifting could have been done with some simple triggers. But instead
"microservices". That worked ok when there was only one instance of each
service, but then when app engine scaled up it became a knot of race
conditions.

~~~
RussianCow
For the record, I do agree with your general sentiment that many of these
abstraction layers are unnecessary, and in many ways harmful. Especially when
it comes to data integrity, trying to enforce constraints and triggers at the
application level is always going to be clunky and error prone, and monolithic
frameworks like Django and Rails actively encourage you to do everything at
their level and give you many ways to shoot yourself in the foot. But I also
don't think Hasura and Postgraphile and related projects are the silver
bullet. Why can't we have something in the middle? How about a web framework
that leaves data integrity up to the DB and just gives you an easy way to
"glue" together bits of logic and queries, and do migrations, etc? Or even
just use Django/Rails/whatever but don't use the footgun features? At least
then, if/when you _do_ need to scale (in any sense of the word) past what a
relational DB can offer you, you can easily do that instead of trying to
shoehorn everything into the DB.

Aside: I'm working on a GraphQL library for Python that I hope will fulfill
these goals, but development on it has stalled due to lack of time. Hopefully
I can pick it up again soon.

FUD may have been strong, but in general I detest when people decry entire
categories of technology as being "wrong" or unfit in an absolute sense (or,
conversely, tout a technology as a silver bullet), when in fact everything has
its tradeoffs and there are good reasons to use almost anything. Understanding
those tradeoffs is vastly more important than searching for the universal
answer to everything.

PS: Hope you're doing well! :) Your contact info isn't on HN, but email me if
you want to get coffee/lunch sometime!

------
hn_throwaway_99
I looked at Hasura a while back, and to be honest I thought it was the
antithesis of all the things I loved about GraphQL so I moved on. Perhaps
someone can convince me differently?

The thing I love most about GraphQL is that serves as the perfect _contract_
layer between the front end and the backend. A very productive development
method I've used is to have the front end and back end teams agree on the
GraphQL types (often times having the front end folks actually write the
types), quickly mock things out, then have the front end folks go implement
the front end and the back end folks provide the real resolver
implementations.

The things I love about this is that it really simplifies and hides the
backend details from the front ends. With things like Hasura, you are
_directly_ exposing your DB schemas to the front end, essentially tightly
coupling them together. That has always been a recipe for disaster whenever a
project gets sufficient scale or complexity in my opinion.

Again, it was a long time ago when I dug into Hasura, but this whole concept
of "Directly expose my DB schema as GraphQL" is the exact opposite of what I
love about GraphQL in the first place.

~~~
brillout
Do you really need to decouple frontend and backend in the first place?

Why not separating concerns instead of separating technologies? Tight coupling
of UI with database but decoupling of e.g. admin UI/backend from end-user
UI/backend.

I'm the author of a Node.js RPC implementation
([https://github.com/reframejs/wildcard-
api](https://github.com/reframejs/wildcard-api)) and the idea is the exact
opposite of what you are prescribing: highly coupled frontend business logic
with database schema/queries. Makes things so much simpler, in my experience.

------
crubier
After trying Hasura, Prisma, and PostGraphile, my conclusion is that
PostGraphile is way ahead of all this. Please all have a look at PostGraphile,
it is amazing, even more than Hasura!

~~~
pier25
Can you elaborate?

~~~
crubier
There are so many good reasons to use it that I think I don’t make it justice.
But here a few pros of graphile:

\- it is made in typescript and can be integrated as a library directly in a
JS project

\- it is very easy to extend with plugins

\- it is very easy to customize and run on an existing database

\- it is « database first » in the sense that the schema is created based on
the DB schema and some additional annotations

\- it is really free open source software with a non-VC backed business model

\- it is extremely performant

~~~
pier25
I don't have any horse in the race but other than the "it is made in Node"
everything else applies to Hasura (except the VC thing obviously).

Do you have any other point to sustain this comment of yours?

> _my conclusion is that PostGraphile is way ahead of all this_

~~~
crubier
I mean:

\- Like Hasura, has ALL the features of Hasura

\- BUT really FOSS with no VC funding, supported through Patreon by a super
nice team.

\- AND I have all the source, in the same language than the rest of my stack,
the language that my developers know

\- AND it does not require to run yet-another-microservice but is just part of
my graphQL server

\- AND it is extensible through plugins that blend seamlessly in the server
(unlike Hasura where I see no sign of plugins, and I don't want to write
plugins in Haskell)

\- AND it supports native, super-fast Postgres Row-Level-Security instead of
rolling their own!

That is very clearly compelling enough to support my conclusion, from my point
of view.

Let me also mention that I have been burnt by another VC-funded GraphQL server
company, namely Prisma, which left us stuck with an old, non-maintained buggy
version which is near impossible to patch and build ourselves, while they work
on their pie-in-the sky Prisma v2 which is totally the wrong direction in my
opinion.

We jumped ship from prisma, considered hasura, but went for graphile and love
it!

~~~
pier25
Don't get me wrong, I agree with most of your points as I'd prefer to work
with Node than Haskell, but I still don't see how it is "way ahead" of the
other options outside of personal preference.

Unless I'm missing something, Hasura is FOSS too.

[https://github.com/hasura/graphql-engine](https://github.com/hasura/graphql-
engine)

True, Hasura does not have plugins (AFAIK) but you can extend it's
funcitonality via webhooks and PG views.

As for authorization it may give them more flexibility to roll their own.

Anyway, thanks for bringing up PostGraphile. I'll check it out!

------
kandros
While I like and enjoy many aspects of code generation such as this or Prisma,
In real world scenario it just doesn’t feel right.

Imagine a very simple scenario, you want to add some validation based on
business requirements, in order to do that you have to have a server with
custom endpoints or a custom graphql server (thus copy most of what hasura
generates) to implement your own validation

The only situation in which I consider this a really good solution is in a
CQRS system where the database attached to hasura is read only via graphql and
the data is inserted by other services making it a typesafe single source of
truth to read from

~~~
endymi0n
Often times that’s not needed if you actually use the full power of PG. CHECK
constraints go a long way, and where they don‘t go, PG/PSQL goes pretty much a
long way.

For internal or prototypical use cases, that can be totally sufficient,
however you‘re right that you‘ll eventually want good error messages,
observability and much more other custom logic.

What I‘m still searching for is something that works like Hasura or PostgREST
and then offers „upgrades“, first via configuration, later via custom code
hooks.

That would be pretty awesome from a migration path perspective.

~~~
lurker2003
Check out Postgraphile, it allows you to start off with introspection, then
customise it with comments, then add custom bits in node.

Both Hasura and Postgraphile also support schema stitching from what I know,
so you should be able to extend it that way also (more complicated obviously)

------
michelpp
A huge benefit that tools like Hasura, Postgraphile and PostgREST provide is
using the native in-database row level security model.

Consider Django. Your django app logs into the database typically as a user
with elevated permission that is a superset of all permissions required by
your users. Postgres has no idea that django is acting on behalf of many
users, all it sees is this django super-like user. If an attacker roots your
Django instance, they have the same privileges. If your PHB decides to "help"
and log in with creds found in the source code, the damage could be
catastrophic.

Products like Hasura, Postgraphile and PostgREST switch databse roles on the
fly per-request. The user that these tools logs in as typically has almost no
privileges. You must be the bearer of a valid JWT token to elevate privileges,
and then you only get to the level of the user you stole the token from. There
is NO super-like user.

~~~
sfilipov
> A huge benefit that tools like Hasura, Postgraphile and PostgREST provide is
> using the native in-database row level security model.

I agree with your overall comment. Note that Hasura doesn't use the native row
level security in Postgres. They implement the layer themselves. There are two
reasons: 1) Hasura is older than the first release of Postgres that included
the row level security feature. 2) Their implementation scales better when
there are a lot of users subscribed to the same GQL Subscription. When using
row level security, every user's query result looks different, so they need to
create a database subscription / polling for each user GQL Subscription. Their
implementation allows them to have a single PG subscription (well they mostly
do polling), get all the data back, then strip down on the way out to the GQL
subscribers.

------
haolez
I tend to prefer PostgREST's[1] syntax over GraphQL for when I need flexible
client-side queries. It's way more intuitive for me.

[1][http://postgrest.org/](http://postgrest.org/)

~~~
marton78
How do you make subscriptions work with PostgRest?

~~~
haolez
Probably by returning an endpoint and a token to a service that will handle
the perpetual session.

The scope is smaller than GraphQL, but some of the interesting benefits - like
smarter and more optimized requests - are available with PostgREST.

------
sadturnip
I tried Hasura in the past and unfortunately found it unsuitable for our auth
requirements. There is no way currently to hook into their authorization
system, you get extremely basic RBAC and if that isn't good enough for you too
bad.

For example we currently are required to talk to some external auth services
(depends on the customer) and fetch the users permissions based on that, (e.g.
user can READ notes, and WRITE notes but not delete NOTES). At the time we had
an extremely simple express middleware that handled this.

Also the entire idea that i need another GraphQL or rest server to do any sort
of custom validation/custom actions made me do a double take and more or less
killed any interest to me.

We ended up using NestJS with their GraphQL tooling and objection.js and never
looked back. Ironically the adoption of the GraphQL version of our API
compared to Rest is almost 0.

~~~
tango12
Hasura's authz is whatever authz you can derive from the data within your
database or from the claims embedded in the authn token. If you have a table
that contains the claims for each user, then you can reference that in the
authz rule for any other table/view/function. READ notes if
user.is_note_reader = true.

We're working on making it easy to integrate resource claims and rule engines
that are external as well (make an IO call instead of embedding the rule in
the SQL query itself). The good news is that it is possible to do at the
Hasura layer because Hasura owns the RBAC so we'll get to it soon enough :)

Over the last few months, we've seen users flip from their custom GraphQL
servers to using Hasura because of the reduction in code/maintenance that
Hasura brings for their use-cases. Especially when you have a large number of
tables. Being able to manage authorization rules at a "type" level instead of
a "resolver" level also makes things convenient.

We've also started work on making it easy to integrate REST APIs for custom
logic (esp writes) which also helps skip a bunch of GraphQL/authz boilerplate:
[https://blog.hasura.io/introducing-
actions/](https://blog.hasura.io/introducing-actions/)

~~~
sadturnip
Unfortunately we do not have these claims defined in our auth token or the
datasource hasura is attached to. We have an external session cache service in
Redis. If the user isn't cached we need to hit an internal API to attempt to
fetch this information for us and return it to us. No user information is
stored in our auth token/database.

Actions look painful, i don't want to write and maintain microservices just to
do simple actions. I just want to be able to write code and handle the hook
around the function. Also from the link it only seems like actions occur AFTER
something happens, i need the ability to run before changes are persisted.

------
yen223
It's definitely cool to see Haskell projects getting used in industry. I am a
big fan of Hasura and the value it gives in the GraphQL space.

------
shivekkhurana
I settled for Hasura in a prod app after trying Postgrest, Postgraphile and
Strapi. I believe its a permanent addition to my stack.

The main reason for me was RBAC. Converting db-to-api is not that hard but
providing access control almost always requires some form of middlewares.
Hasura does RBAC very well.

Another feature that I haven't deployed but find useful is webhooks. You can
trigger webhooks as your data changes.

I do need a server to handle object storage, email and cron so it's not a 100%
there, but I can see the appeal of rapid APIs at low cost.

Also subscriptions are <3.

All the best to the Hasura team.

~~~
markhalonen
What made you choose Hasura over Postgraphile? RBAC is a postgres feature, not
sure if that would affect the decision?

~~~
aidos
Not the parent but we went with Hasura over postgraphile because they do RLS
outside of the dB. It allows them to load the data for all clients subscribed
in a single query. Also the subscription story is better (from memory).

------
MadWombat
One thing that bothers me about systems like this is the underlying assumption
that database architecture always reflects the presentation. But what if ti
doesn't? I am looking at the Hasura docs and all it really says is "we will
generate everything for you based on your database schema and here is the way
we do it". But what if I don't want some tables to be exposed? What if I want
to expose custom queries instead of tables?

I feel that products like Hasura and postgrest would be a lot more useful if
there was a way for me to specify a list of data sources on one side and get a
fully formed GraphQL or REST service on the other side rather than going "I
know what you need better than you" route.

~~~
batmansmk
Data-driven architectures are very relevant, in particular in a corporate /
business environment.

I found all the answers in the docs.

A SQL Schema can carry a custom query, it's called a view.

A SQL Schema can carry a custom algorithm, it's called a function or a
generated column.

You can always deactivate permissions on a table to not expose it, my bet is
that your backoffice will need to though.

On top of that, Hasura supports custom resolvers (code driven endpoints).

Finally you can stitch 2 GraphQL schemas together. It doesn't have to be one
size fits all. So even if only 50% of your app can fit in the model of Hasura,
you can always mix and match. It's still 50% that will be up and running in
minutes.

~~~
MadWombat
> A SQL Schema can carry a custom query, it's called a view.

This is not feasible. I might not have enough access to create views. I might
not have access to create functions. I cannot deactivate permissions if I only
have a single access account and other systems use it already. You cannot
assume that I have full control of the database or that I can easily make
changes to the schema.

But this is not all. I am working on a web backend project on daily basis. I
would love to offload some basic CRUD operations to something like postgrest
or implement GraphQL with something like Hasura, but I need a way to a) define
table and field name mappings b) define what tables are accessible b) define
what columns are visible c) define what nested relationships are allowed d)
define actions that need to happen on update/insert/delete operations (i.e.
push a message into a queue every time a record is deleted from table T) If I
could do all of this, I could implement about 50% of my web service and it
would be useful.

~~~
batmansmk
Please read the docs. All your fears are addressed in the doc. The permissions
are managed on the Hasura side.

Concerning the lack of sufficient privileges to create a view, you can always
either ask for permissions, or create a second databse with FDW. Apparently
reading your second paragraph you are allowed to create tables, so it sounds
like you'll also have enough privileges to create views.

I don't understand your point on your second paragraph. You can do all of that
in Hasura, it's in the first tutorial, but also the doc. Please note we are
talking GraphQL so there is no CRUD. It is a query + mutation model. More
flexible and powerful than CRUD.

------
benfle
Is it a good idea to base your GraphQL schema on your database schema?

Isn't the point of GraphQL to decouple your interface (who should not break)
from your backend implementation details?

~~~
michelpp
> Is it a good idea to base your GraphQL schema on your database schema?

You don't. Hasura (and Postgraphile and PostgREST) employ in-database modeling
tools called views. Views provide the same modeling abstractions that ORMs
provide.

[https://www.postgresql.org/docs/12/sql-
createview.html](https://www.postgresql.org/docs/12/sql-createview.html)

A view is a canned query with a name, and when you get down to it, all an ORM
is doing is producing, usually poorly, a query from a named abstraction. Same
thing. So why have two pieces in two languages when you can have one?

> Isn't the point of GraphQL to decouple your interface (who should not break)
> from your backend implementation details?

Views provide the same or better decoupling. They database is aware of them,
they are type checked, you can't even make a view that references an unknown
column, for example.

------
afvictory
Congrats to the Hasura team!

Hasura is truly a marvelous piece of software when it comes to rapidly
prototyping and getting things out into production. We discovered Hasura a
couple years back at my previous company when it was still in beta and we were
amazed with how easily we could automate most of our CRUD logic. I will
definitely be using Hasura again when the time comes around.

On a more recent note, I currently have a client who's prototype was built
with Hasura but one of their requirements was to migrate to AWS and use as
many of the PaaS offerings as possible. We ended up using AppSync[1] and it is
fairly impressive. I highly recommend anyone who is stuck in the AWS ecosystem
to check it out. AppSync integrates with a lot of other AWS services (Cognito,
S3) very easily and allows you to use Dynamo/Aurora/RDS/Elastic as data
sources. On top of this, you can also use Lambda to implement resolvers that
need more intense business logic, making the service incredibly powerful.

[1] [https://aws.amazon.com/appsync/](https://aws.amazon.com/appsync/)

~~~
adminu
We used appsync at my company and switched to a more classical approach of
handwritten crud, a REST Api, a RDS (not entirely sure how well you can use
them with appsync) away from dynamodb. Appsync was just not mature enough, had
bugs and severe limitations. Without someone in the team who really knows
Appsync, I would recommend against it and towards the tech you know.

~~~
afvictory
What was the biggest hurdle you ended up facing that ended up being the
dealbreaker for your team?

I think for us, the biggest issue so far has been figuring out some of the
more involved Velocity templates as the documentation is fairly sparse and
testing them can be a pain. Thankfully this project isn't too business logic
heavy but due to time constraints, we ended up writing Lambdas for templates
we could not figure out quickly.

------
ihodes
I'm curious if anyone here has compared Postgraphile to Hasura? My personal
difficulty in implementing these is that there aren't good source control and
code organization tools for SQL and managing rollbacks and rollforwards in a
sane way.

(And a way that doesn't require writing rollbacks, which sometimes aren't even
possible anyway).

~~~
sastraxi
I've done exactly that with a sample food delivery project. Same frontend, but
two different backends (one with Hasura, one with Postgraphile).

Feel free to check it out: [https://github.com/sastraxi/great-
bear](https://github.com/sastraxi/great-bear)

~~~
ihodes
This is very cool, as is your git-like tool for PG! Thanks for sharing.

------
aloukissas
I want to bet there were zero Greek VCs in the round :D (in Greek, "hasura"
means huge loss, especially in investing context)

~~~
bdcravens
Odd. Google Translate says it's "encountered"

[https://translate.google.com/#view=home&op=translate&sl=el&t...](https://translate.google.com/#view=home&op=translate&sl=el&tl=en&text=hasura)

~~~
aloukissas
You're looking something more like
[https://translate.google.com/#view=home&op=translate&sl=auto...](https://translate.google.com/#view=home&op=translate&sl=auto&tl=en&text=%CF%87%CE%B1%CF%83%CE%BF%CF%8D%CF%81%CE%B1)

The spelling "hasura" is in what we call "Greeklish", i.e. Greek in English
(ASCII, really) characters. This was common in early 2000s, where utf-8
support was not everywhere (web, SMS, etc) and writing in Greek characters had
a high chance that the recipient would receive mumbo-jumbo.

------
worldsayshi
I often miss graphql features when working with rest APIs. But switching over
seems very much not worth it when no one in the organisation knows graphql.

I feel like graphql would be much easier to adopt of it just sticked to rest
conventions as much as possible. Like have the query language be pure JSON.

It should even be possible to design it so that you could make drop in
replacements for most of existing rest APIs.

~~~
kandros
GraphQL is much easier to pickup and get productive than most people think,
most of the times all you have to do is writing resolvers (functions) instead
of http handlers (functions)

On the client side is the same, following any getting started guide can
explain 90% of what you need to know in a single day

~~~
vlozko
Client side GraphQL is harder than REST, though I wouldn’t define it hard in
general. Whereas with REST one only needs to update the data model for the
response, GraphQL also requires that the request itself is also updated. It
gets more complex if the client wants to take advantage of hashed queries and
now there’s all this work needed to upload the queries to some backend
service. This is from my own experience — I haven’t worked with Apollo to know
how much of this process is simplified for you.

~~~
kandros
The situation you are referring to is actually a great plus, If you change the
data model in you backend, you client consume it and thus depend on it, so you
still have to change the frontend code anyway, knowing exactly what you can
ask and how it will come back makes it a very powerful developer experience
with a lot of test that don’t need to be write thanks to tooling around a type
system and a faster feedback loop.

~~~
vlozko
Oh, I’m not suggesting that it’s a worse way to do web requests at all. I
genuinely enjoyed working with GraphQL despite all the build/CI headaches it
can potentially cause. I was really addressing the sole point of difficulty of
working with REST vs GraphQL and I’d unquestionably say REST is easier. It’s
not a statement of which one is better or worse.

------
skinnyarms
I'm excited anytime a technology comes along that makes for great user
experience AND developer experience. I can demonstrate the value that Hasura
provides to either side in minutes.

The subscriptions are particularly interesting to me, I've never seen anything
else that makes web sockets so easy to implement. I'm very optimistic for
their future.

------
gsvclass
Not a startup but still a very feature rich GraphQL to SQL compiler service
works with Postgres and YugabyteDB. Written in GO.
[https://github.com/dosco/super-graph](https://github.com/dosco/super-graph)

------
headgasket
I've been using postgraphile over hasura for while, initially because of some
JWT business. That thing rocks. RBAC and JWTs are a killer feature for public
facing stuff.

Congrats to the folks at hasura for the raise, long live postgres and graphql.

------
wesleyfsmith
Can someone explain to me how this differs from Apollo? Is it that it has a
tighter integration with the DB layer?

------
armatav
Firebase, React and Hasura let me set up new app ideas in like negative time.
Hasura is especially amazing because of it's authentication handling and
migration management.

~~~
elitan
That's super fast!

------
rayraegah
Tooling around Hasura is starting to mature. People have already mentioned
nhost, I’d also like to point out a terraform module [0] to put Hasura on AWS

[0]:
[https://registry.terraform.io/modules/Rayraegah/hasura/aws](https://registry.terraform.io/modules/Rayraegah/hasura/aws)

------
brillout
Instead of Hasura and GraphQL, you can use RPC and directly write SQL queries
to retrieve and mutate data.

One way to think about this is that with RPC you remove the whole API layer
and directly write SQL queries instead, while permissions are defined
programmatically on a case-by-case basis. This is much simpler than Hasura!

For Node.js there is [https://github.com/reframejs/wildcard-
api](https://github.com/reframejs/wildcard-api).

For other backends you can implement JSON endpoints
([https://github.com/reframejs/wildcard-
api/blob/master/docs/b...](https://github.com/reframejs/wildcard-
api/blob/master/docs/blog/rest-rpc.md#json-endpoints))

While scaling to a large company, you progressively migrate from RPC to
GraphQL (with or without Hasura).

~~~
miles-po
I appreciate your zeal in marketing this product, but you're comparing apples
and oranges. You are speaking of the ease of how you can write SQL queries.
With Hasura, Postgraphile, Prisma, and their generated REST counterparts, you
aren't writing any SQL queries. You are creating your database schema and then
launching the respective apps. Obviously some customization will be necessary
since almost no app are 100% CRUD.

But I took a look at your RPC tool, and it adds a lot of boilerplate work.
This RPC boilerplate is exactly why alternatives like Hasura, Prisma, and
Postgraphile exist.

Also you can't add an RPC layer and magically call it simpler. If you add
Postgraphile, Prisma, Hasura in front of the database, it is just as simple,
just as much a layer on top of the database. Only in this case you're writing
to a published open spec (GraphQL) so the client doesn't have to know if it's
talking to a relational database, a Redis cache, a REST data server, an in-
memory data model, or whatever.

Your tool on the other hand is just another vendor-specific ORM or manual
query engine. If that works for you, great. It is not a good alternative or
answer to what is being discussed here.

~~~
brillout
> you're comparing apples and oranges

I agree, Hasura and Wildcard have different goals. Still, the merits of each
tool can be talked and discussed about.

> you aren't writing any SQL queries. You are creating your database schema
> and then launching the respective apps. Obviously some customization will be
> necessary since almost no app are 100% CRUD.

I'm not against ORMs. On the contrary, I've always been (and still am) looking
for an ORM that takes care of 90% of queries (basic CRUD queries) while
preserving the full power of SQL for the 10% of queries that require more
powerful queries. Most ORMs do that part wrong and make writing custom SQL
queries complex. I really want such ORM and I even tinkered and implemented
one for a hobby project.

Also I believe that an ORM to be a wonderful combo with Wildcard, such as
Prisma. (Prisma is pretty much an ORM and can be used without GraphQL.) I
would argue that Prisma + Wildcard to be superior to Prisma + GraphQL. (With
the exception of when you need need third-party devS to access your data --
you then need a generic API with either REST or GraphQL.)

> But I took a look at your RPC tool, and it adds a lot of boilerplate work.

I couldn't disagree more; Wildcard is deliberately designed to abstract away
as much boilerplate as possible. I'd be more than happy to see a concrete
example that proves me wrong. My guess is that you won't prove such example
because there virtually isn't such.

> This RPC boilerplate is exactly why alternatives like Hasura, Prisma, and
> Postgraphile exist.

That's a vague sentence and doesn't make any sense to me.

> it is just as simple, just as much a layer on top of the database.

Wildcard is only a couple of KLOCs while Hasura & co large and complex tools
developed by teams and backend by big VC money.

You can read Wildcard's whole documentation in 10 minutes. Reading Hasura's
entire documentation is _much_ larger than Wildcard's.

It speaks volumes about how much simpler Wildcard is in comparison to Hasura.

It's weird to say that Hasura is as simple as Wildcard.

> the client doesn't have to know if it's talking to a relational database, a
> Redis cache, a REST data server, an in-memory data model, or whatever.

Such decoupling is mostly useful for very large projects. The vast majority of
apps out there don't need such decoupling. Separation of concern is important,
but based on _concern_ not on technology.

> Your tool on the other hand is just another vendor-specific ORM or manual
> query engine.

It's weird to call an RPC implementation an "ORM" or "query engine". I'm not
sure how an Software Engineer is able to mix up "RPC" with "ORM".

Honestly, your whole post is weird to me, I'm not sure what your motive is.
You seem to try to put down an open source project that is being developed by
someone in his free time and without any remuneration. That's disgusting and
without taste. If you only have a lack of tact then I apologize for my words.

Just to be clear I do like many aspects of Hasura. The problem is that, 95% of
the time, GraphQL is not being used in the right situations. GraphQL when used
correctly is a lovely tool. (Basically GraphQL = generic API for third
parties. If you don't need third parties to access your data then you don't
need GraphQL.)

~~~
miles-po
Okay, let's spell it out. Your tool requires that you specify endpoints. Then
call the ORM or make manual SQL queries. In the example, you have a Todo
object.

Do you see the code right here? ``` endpoints.createTodoItem = async
function(text) { ... } ``` You've already missed the point of tools like
Postgraphile et al when you propose tools like that in a discussion like this.
You don't have to write endpoints or even GraphQL schemas _at all_. You
literally just start the tool, passing in the database connection info, and
start using it. That's it. That's all. That's what I meant by simple, not how
many lines of code they required (which is not much of a benchmark). That's
what I meant by apples and oranges. I'm sorry you saw that as an attack, but
it's true. It is not just a matter of replacing GraphQL for RPC as you
suggest. Or REST for RPC. Simplicity from the point of view of the user, not
the server parsing code. Your server is effectively writing a data schema to
be consumed by a client. These GraphQL tools write the schema for you.

No code at all (other than database setup) is required to get this working.
Zero. [https://www.graphile.org/postgraphile/usage-
cli/](https://www.graphile.org/postgraphile/usage-cli/)

I hear you on the comment "Is your API meant to be used by yourself? Use
Wildcard." However at that level, ANYTHING works. If you start with REST or
GraphQL, you may not need it now, but if your project grows, you'll have to
rewrite everything. Another minor nit: GraphQL does not require HTTP or even a
network layer. GraphQL in and of itself is 100% transport-agnostic.

Sure you could auto-generate RPC endpoints from your database schema, but that
requires a tool that does not yet exist, does it? And at that point, what
advantage does it afford over GraphQL? It's not markedly more efficient. For
that matter, if you wanted the most efficiency regarding RPC, why not use
something like gRPC that uses protocol buffers for serialization? If that
level of efficiency isn't necessary, then how can you criticize minimal
protocol efficiency differences between RPC and GraphQL?

Then there's the issue of vendor lock-in. GraphQL is a spec, and a relatively
simple on at that. Nothing more. Nothing less. For the most part different
GraphQL backend implementations can be replaced with another
vendor/implementation. REST is the same. Can the same be said of your RPC
implementation? Could someone seamlessly replace it with another tool without
changing _any_ client code? Who are your competitors? (Not necessarily looking
to outdo you, just occupying the same spec-level niche.)

As for VC funding, Hasura just got some. Prisma has some. Postgraphile is a
one-couple shop with a simple Patreon. The REST libraries don't have VC
funding to my knowledge, so that comment from you was largely unwarranted and
frankly rude. But more to the point, lack of funding or a development team is
not an effective point. What happens to the organization using your software
if you get hit by a bus? Why should they take on that risk? Sure they can take
over your code since it's open source, but if they wanted to go down that
road, why wouldn't they just write their own code anyway? I'm not saying you
have to be a major multinational corporation, but single points of failure are
not selling points to most folks whether those single points of failure be
technical or social.

Lack of redundancy is a hazard. Lack of choice is a hazard. I for one am glad
so many healthy competitors exist in the auto-conversion of relational
databases to GraphQL.

All the best of luck to you in your RPC endeavors. I'm sorry for being harsh,
but you jumped into multiple threads promoting Wildcard without in my opinion
understanding what you were comparing against. I hope you find an appropriate
audience and user base for it. I fear however that this isn't it for the
reasons I enumerated.

~~~
brillout
I appreciate your elaborate answer. Thank you.

I'm a minimalist and as such I have a problem with complex solutions to simple
problems. That's my whole point.

My dream ORM is a an ORM that is designed with a) an obsession on simplicty,
b) simple ORM CRUD queries that cover 95% of the data mutation/retrival needs,
c) allows you to write "native" (no)SQL queries directly for the 5% cases when
you need more complex queries, and d) automatically takes care of migration
for 90% of the cases.

The ORM should be trivial to understand, the documentation super small, and
the ORM should get _entirely_ out of your way if you want to use your database
directly without the ORM. Most ORMs out there (if not all) get these things
wrong.

Hasura, Prisma & other auto-generated GraphQL tools are essentially ORMs.
Unfortunately, they also get the above listed things wrong. I like that they
auto-generate a GraphQL schema, that's neat. That's not my problem. My problem
is that they are tightly coupled with GraphQL. That's nonsense. Because (and
Wildcard is a living proof of this) _you don 't need_ GraphQL for the vast
majority of apps out there. People need to understand that GaphQL = generic
API = third-party devS. You don't need to expose your data to third parties?
You don't need GraphQL. Period. (I hear people arguing about decoupling
frontend and backend by using a generic API but that's an old and out-dated
idiom, which is another topic I'd be happy to elaborate if you want.)

A simple ORM with a plugin that auto-generates a GraphQL schema? Hell yeah
that's awesome. You'd then use the GraphQL plugin _only_ when you need to
expose your data to third parties. That's cool.

You don't need to expose your data to third parties? Use an ORM with RPC.

RPC is _fundamentally_ simpler than GraphQL. Why on earth should I use
something inherently more complex if I can use something so much simpler?

For example, have a look at how permissions work with Hasura and compare this
to Wildcard. The difference is worlds appart in simplicty.

With Wildcard, permissions are written in code:

    
    
        // Node.js server
        
        endpoints.deletePost = async function(){
          // Only admins are allowed to remove a post
          if( !user.isAdmin ) return;
        
          // ...
        };
    

This means that you don't have to understand anything to do permissions --
simply write if statements, just like you are used to while programming other
sutff.

With Hasura, you have to use Hasura's custom system of role-based permissions.
What I find most annoying about these is that they are not defined in code.
With Wildcard all permissions are written in the code - I can simply read them
while reading queries.

I hear your arguments saying that Wildcard is new and I understand that you
don't want to adopt something that is the "bleeding-edge". (From my
perspective; from your perspective, experimental ;-).)

I agree that my way of promoting Wildcard on the whole Hasura thread was less
than ideal, I'll improve.

~~~
miles-po
In code, as long as that code is JavaScript. Looking at endpoints.getPost,
assuming you pass in an id, what does that result look like? "It can look like
whatever query you're making" is not a good answer. Even if you're the only
developer on a project, code you wrote six months ago might as well have been
written by someone else.

Let's look at a GraphQL call in terms of simplicity.

    
    
      await fetch({
        method: 'POST',
        url: 'http://server/',
        body: `mutation {
                 deletePost(id: '542543') {
                   id
                 }
               }`
      });
    

That's it for a client call, and I know from the query that it'll return the
id of the post (if any) that was deleted.

Using Postgraphile as an example, nothing to do on the GraphQL server side
beyond starting it up. In your database:

    
    
      CREATE TABLE post (
        ...
      );
      REVOKE ALL ON post FROM public;
      GRANT SELECT INSERT UPDATE ON post TO public;
      GRANT DELETE ON post TO app_admin;
    

Done. The issue with your approach is that different sections of code may
invoke SQL that deletes data. Once a data model lives long enough, edge cases
show up. By having the security model live with the data itself, you never
have to worry about these edge cases. Set theory for the win! Security bubbles
up from the data layer, through the app layer, to the client layer. Also means
that if you have two apps talking to the same database, you are no longer
required to keep those security restrictions in sync. Got one app in PHP with
another in Ruby? No problem. Data security is still intact. Forgot to restrict
deletes? Fix the data layer, and the security fix bubbles up. No worrying
about all of the possible places that might be affected by this.

Data security at the app level is arguably the wrong level to be implementing
it.

Now you may decry the complexity of a fully-formed solution, but honestly
Postgraphile meets your requirements quite well. GraphQL really isn't complex
on its basic level.

    
    
      query {
        post(id: 13245) {
          id
          subject
          body
          author {
            id
            name
            email
          }
        }
      }
    

Boom. That's the JSON that comes back—follows the structure of the query.
Self-documenting. The generated CRUD endpoints cover 95% of needs. Native
queries written with the database itself and exposed as functions. Migrations
should be handled as either idempotent SQL DDL or repeatable sequence of files
at the database level, not the app layer.

Performance-wise, I strongly doubt you'll be faster/more scalable that
Postgraphile out of the box. And just because the browser isn't calling the
endpoint doesn't mean that GraphQL or REST are useless. Far from it. It's
absolutely not just for publicly accessible APIs. That is a false assumption
on your part.

GraphQL really isn't as heavyweight as you seem to presume it is. It's just a
spec. How someone implements that spec is what makes the difference. As far as
request/response sequence, GraphQL is quite cheap computationally. Well
documented. Only as complex as the queries you want to make. Hierarchy-aware.

You might as well argue that HTTP is too complex and inefficient; that raw
socket calls are better. Why not set up an exokernel?

The reason most of us don't is that it violates the 80/20 rule. Premature
optimization and all that. If 99% of the time is spent in the database doing
queries and only 1% in your app, fixating on the "efficiency" or perceived
"simplicity" of that 1% is a fool's errand.

------
treyhuffine
Very excited to see this. Hasura has transformed how I build apps.

------
caniszczyk
Awesome to see the GraphQL community growing, there's a GraphQL Landscape of
tools out there, if something is missing please contribute, the GraphQL
Foundation is tracking everything now:
[https://landscape.graphql.org/](https://landscape.graphql.org/)

~~~
miles-po
Not clear how to add or notify anyone to add. Missing Prisma
([https://www.prisma.io/](https://www.prisma.io/)) and Postgraphile
([https://www.graphile.org/postgraphile/](https://www.graphile.org/postgraphile/))
in the Databases section.

------
erdaniels
Disclaimer: I work on MongoDB Stitch

This looks really cool and an improvement on Prisma! I particularly like the
much less bloated schema experience (and the builder) along with the easy
addition of actions. We've been working on something similar but it's great to
see improvements in the UX of the space.

~~~
jackdh
Do you have anything to add about Hasura? Or is this just a straight plug for
stitch?

~~~
erdaniels
Yep, I modified my comment. I meant to put it as a sub-comment where it
contextually made more sense.

------
buhrmi
If GraphQL needs $9.9M to be simple enough for developers to actually use it,
why was it invented?

~~~
deckard1
GraphQL is mediocre. It's luke-warm mashed potatoes from a chain diner.

Having used it for a number of years now, I still don't know why people
recommend it beyond other people recommending it. Out of the box, it comes
with no batteries included. Which explains the cottage industry that popped up
to support it (Apollo, Hasura, etc.). Simply making GraphQL as efficient as
bog-standard REST without involving the use of half a dozen 3rd party
libraries is a fool's errand.

Silicon Valley suffers great amnesia and NIH. We've had RPC forever now. XML
RPC, SOAP, thousands of others that don't deserve mention. There is a reason
people moved from SOAP to REST: you didn't need that complexity. (On a side
note, it makes me incredibly depressed to be in this industry knowing how much
time and effort died trying to make XML a thing. When was the last time you
heard "XML" on Hacker News? Probably been awhile. Maybe 5-10 years now. As a
piece of news that is, and not some random comment from an asshole like me.)

Requesting arbitrary pieces of data on the client side (GraphQL's seemingly
raison d'etre) is quite easy with REST. So easy that it makes me curious how
much brain damage the industry has to think otherwise. Creating new endpoints
even? Not a big deal. Not nearly as big of a deal as writing the mountains of
boilerplate to get a new GraphQL query up and running. And considering we're
talking about GraphQL, it's most likely going to be the same team members
working on both sides. Why would that not be the case for REST as well? The
mind boggles. All the arguments against REST that GraphQL camp makes are
disingenuous at best.

~~~
markhalonen
After using GraphQL with code-generated Typescript types on the response, I
can't imagine going back to REST and it's "hope and pray" the JSON looks how
you expect it to look

~~~
karatestomp
I think part of the actual, non-hyped benefit is that it adds type definitions
to incoming and outgoing fields on the client side. Working directly with JSON
is kind of fucking awful. Attempts to fix it are often of an even more
unpleasant "now you have two problems" sort (JSON-Schema, for example). Any
well-supported standard for typing interfaces for data sent to the browser &
other REST-consuming clients, even if the underlying transport remains JSON or
whatever, is welcome.

------
z3t4
Myt pet peeve with GraphQL is, why not just use JS objects, and use JSON for
serialization!? query = {user: {id, name}}

~~~
tango12
There are quite a few ongoing attempts at creating a JS fluent client for
GraphQL.

We covered a bunch of them here:

[https://hasura.io/blog/fluent-graphql-clients-how-to-
write-q...](https://hasura.io/blog/fluent-graphql-clients-how-to-write-
queries-like-a-boss/)

------
k__
A small comparison:

[https://www.moesif.com/blog/graphql/technical/Ways-To-Add-
Gr...](https://www.moesif.com/blog/graphql/technical/Ways-To-Add-GraphQL-To-
Your-Postgres-Database-Comparing-Hasura-Prisma-and-Others/)

------
mongol
Does something like this exist for SQLite?

