Hasura raises $9.9M to simplify GraphQL

This is fantastic to see. First time I tried out Hasura back in late 2018 I was AMAZED.<p>After going through multiple different stacks such as MeteorJS, Firebase, building my own REST&#x2F;GraphQL API etc. Nothing really felt right.<p>That was until I found out about Hasura.<p>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: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;HasuraHQ&#x2F;status&#x2F;1068145251267895300?s=20" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;HasuraHQ&#x2F;status&#x2F;1068145251267895300?s=20</a><p>They were all amazed and many use Hasura in production today in their apps.<p>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 &#x2F; REST &#x2F; vendor lock-in).<p>So, I decided to start <a href="https:&#x2F;&#x2F;nhost.io" rel="nofollow">https:&#x2F;&#x2F;nhost.io</a>.<p>Nhost is like Google Firebase but with PostgreSQL and Hasura (GraphQL). Right now providing database, API, auth and storage. Here is a short demo: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=MWB5RXzlJM8" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=MWB5RXzlJM8</a><p>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!

Some major players in the &quot;GraphQL in a box&quot; space:<p><a href="https:&#x2F;&#x2F;www.graphile.org&#x2F;postgraphile&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.graphile.org&#x2F;postgraphile&#x2F;</a><p><a href="https:&#x2F;&#x2F;hasura.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;hasura.io&#x2F;</a><p><a href="https:&#x2F;&#x2F;www.prisma.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.prisma.io&#x2F;</a><p>There are plenty of &quot;REST API in a box&quot; solutions as well:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;PostgREST&#x2F;postgrest" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;PostgREST&#x2F;postgrest</a><p><a href="https:&#x2F;&#x2F;github.com&#x2F;prest&#x2F;prest" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;prest&#x2F;prest</a><p><a href="https:&#x2F;&#x2F;resthapi.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;resthapi.com&#x2F;</a>

Hasura is a game-changer. I&#x27;m never writing CRUD backend apps again by hand.<p>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.<p>This adaptor connects react-admin with Hasura: <a href="https:&#x2F;&#x2F;github.com&#x2F;Steams&#x2F;ra-data-hasura-graphql" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Steams&#x2F;ra-data-hasura-graphql</a><p>Here&#x27;s a reference application I put together: <a href="https:&#x2F;&#x2F;github.com&#x2F;cpursley&#x2F;react-admin-low-code" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cpursley&#x2F;react-admin-low-code</a>

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?<p>The thing I love most about GraphQL is that serves as the perfect <i>contract</i> layer between the front end and the backend. A very productive development method I&#x27;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.<p>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 <i>directly</i> 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.<p>Again, it was a long time ago when I dug into Hasura, but this whole concept of &quot;Directly expose my DB schema as GraphQL&quot; is the exact opposite of what I love about GraphQL in the first place.

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!

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.<p>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<p>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

A huge benefit that tools like Hasura, Postgraphile and PostgREST provide is using the native in-database row level security model.<p>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 &quot;help&quot; and log in with creds found in the source code, the damage could be catastrophic.<p>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.

I tend to prefer PostgREST&#x27;s[1] syntax over GraphQL for when I need flexible client-side queries. It&#x27;s way more intuitive for me.<p>[1]<a href="http:&#x2F;&#x2F;postgrest.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;postgrest.org&#x2F;</a>

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&#x27;t good enough for you too bad.<p>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.<p>Also the entire idea that i need another GraphQL or rest server to do any sort of custom validation&#x2F;custom actions made me do a double take and more or less killed any interest to me.<p>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.

It&#x27;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.

I settled for Hasura in a prod app after trying Postgrest, Postgraphile and Strapi. I believe its a permanent addition to my stack.<p>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.<p>Another feature that I haven&#x27;t deployed but find useful is webhooks. You can trigger webhooks as your data changes.<p>I do need a server to handle object storage, email and cron so it&#x27;s not a 100% there, but I can see the appeal of rapid APIs at low cost.<p>Also subscriptions are &lt;3.<p>All the best to the Hasura team.

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&#x27;t? I am looking at the Hasura docs and all it really says is &quot;we will generate everything for you based on your database schema and here is the way we do it&quot;. But what if I don&#x27;t want some tables to be exposed? What if I want to expose custom queries instead of tables?<p>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 &quot;I know what you need better than you&quot; route.

Is it a good idea to base your GraphQL schema on your database schema?<p>Isn&#x27;t the point of GraphQL to decouple your interface (who should not break) from your backend implementation details?

Congrats to the Hasura team!<p>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.<p>On a more recent note, I currently have a client who&#x27;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&#x2F;Aurora&#x2F;RDS&#x2F;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.<p>[1] <a href="https:&#x2F;&#x2F;aws.amazon.com&#x2F;appsync&#x2F;" rel="nofollow">https:&#x2F;&#x2F;aws.amazon.com&#x2F;appsync&#x2F;</a>

I&#x27;m curious if anyone here has compared Postgraphile to Hasura? My personal difficulty in implementing these is that there aren&#x27;t good source control and code organization tools for SQL and managing rollbacks and rollforwards in a sane way.<p>(And a way that doesn&#x27;t require writing rollbacks, which sometimes aren&#x27;t even possible anyway).

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

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.<p>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.<p>It should even be possible to design it so that you could make drop in replacements for most of existing rest APIs.

I&#x27;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.<p>The subscriptions are particularly interesting to me, I&#x27;ve never seen anything else that makes web sockets so easy to implement. I&#x27;m very optimistic for their future.

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

Not a startup but still a very feature rich GraphQL to SQL compiler service works with Postgres and YugabyteDB. Written in GO. <a href="https:&#x2F;&#x2F;github.com&#x2F;dosco&#x2F;super-graph" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dosco&#x2F;super-graph</a>

I&#x27;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.<p>Congrats to the folks at hasura for the raise, long live postgres and graphql.

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

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<p>[0]: <a href="https:&#x2F;&#x2F;registry.terraform.io&#x2F;modules&#x2F;Rayraegah&#x2F;hasura&#x2F;aws" rel="nofollow">https:&#x2F;&#x2F;registry.terraform.io&#x2F;modules&#x2F;Rayraegah&#x2F;hasura&#x2F;aws</a>

Instead of Hasura and GraphQL, you can use RPC and directly write SQL queries to retrieve and mutate data.<p>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!<p>For Node.js there is <a href="https:&#x2F;&#x2F;github.com&#x2F;reframejs&#x2F;wildcard-api" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;reframejs&#x2F;wildcard-api</a>.<p>For other backends you can implement JSON endpoints (<a href="https:&#x2F;&#x2F;github.com&#x2F;reframejs&#x2F;wildcard-api&#x2F;blob&#x2F;master&#x2F;docs&#x2F;blog&#x2F;rest-rpc.md#json-endpoints" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;reframejs&#x2F;wildcard-api&#x2F;blob&#x2F;master&#x2F;docs&#x2F;b...</a>)<p>While scaling to a large company, you progressively migrate from RPC to GraphQL (with or without Hasura).

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

Awesome to see the GraphQL community growing, there&#x27;s a GraphQL Landscape of tools out there, if something is missing please contribute, the GraphQL Foundation is tracking everything now: <a href="https:&#x2F;&#x2F;landscape.graphql.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;landscape.graphql.org&#x2F;</a>

Disclaimer: I work on MongoDB Stitch<p>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&#x27;ve been working on something similar but it&#x27;s great to see improvements in the UX of the space.

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

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

A small comparison:<p><a href="https:&#x2F;&#x2F;www.moesif.com&#x2F;blog&#x2F;graphql&#x2F;technical&#x2F;Ways-To-Add-GraphQL-To-Your-Postgres-Database-Comparing-Hasura-Prisma-and-Others&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.moesif.com&#x2F;blog&#x2F;graphql&#x2F;technical&#x2F;Ways-To-Add-Gr...</a>

Does something like this exist for SQLite?