It's also really nice, I think the appeal of Hasura is to leverage all the GraphQL clients. Things like Apollo save a lot of time in React and iOS for example since they abstract the whole service layer. I'm not sure if something similar exists for PostgREST.
Totally agree. I recently greenfielded a new project and hasura, postgraphile and Postgrest were all tools I trialed. Hasura has the best “get up and go” but ultimately postgrest was simpler and more intuitive—graphql is cool, but for one person/small team projects it feels like complexity overkill. The added abstraction over rest is just unnecessary with postgrest’s resource embedding. I liked having an admin interface that hasura provided, but really, dbeaver is often just as usable.
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.
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
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.
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.
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.
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.
Looks cool! I cloned it and ran it locally. I noticed there was no backend running locally, and then saw it points to https://low-code-api.herokuapp.com/v1/graphql. Is the code running there available in a repo too? It would be super nice if you could link to it from the project README.
The advantage is React Admin is back end agnostic and you can tap into the huge React ecosystem. And with Hasura you get automatic GraphQL endpoints (Django nor Rails Active Admin do this - you have to create models first vs just a schema with Hasura) which can be used for more than just your admin backend.
Having built and maintained large Django apps for the past couple of years, I personally prefer Hasura's admin console over Django's one, not least because you don't need to write any code to get it started!
Hasura also ships with websocket support, something that Django has always struggled with.
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.
> 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.
> 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.
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!
Part of what I'm doing is working on a CRUD backend.
The thing has a bunch of complex business and authorization rules. Not to mention a bunch of per-client customization. There's also some neat handling around versioning and copy-on-write type behavior to provide a mix of immutability and space saving.
To me, this is CRUD because: most resources literally have 4 endpoints (create, index, update and delete). We write a ton of tests to cover all the cases. It's time consuming, even tedious, and it's boring / simple compared to the user facing stuff we do.
I've never touched GraphQL, so can that really save me months of work? Or would it save me about as much time as Rails would (which would be not a lot) ?
Last time I looked at GraphQL it was only a time-saver if you could rely on significant amounts of automagic for the GraphQL->DB Query step. So if your use case & stack allow for that, yeah, maybe it'll save you significant time.
Its main effect is to move app logic query writing to the frontend, in something that's not SQL, which some folks seem to really like. But it's still got to get turned into whatever your data sources actually speak at some point, just like REST or anything else. If there's nothing magically doing that for you or if the magic turns out to suck, you'll be doing it manually.
[EDIT] to make it more clear, here are your possibilities:
1) a. GraphQL queries -> b. Queries for one or more kinds of datastore
2) a. REST requests -> b. Queries for one or more kinds of datastore
You shift choices about how to query kinda forward in 1, but that means you need a very general and flexible GraphQL query handler to make step 2 happen, and if that doesn't exist or is insufficient you have to write it. That is, obviously, more work than 2, in which 2b is where the choices you'd make in 1a happen, so that layer doesn't need to be as flexible.
TL;DR the apparent flexibility and responsibility-shifting of GraphQL isn't free and is in fact quite expensive (and, if I may, risky)... unless it is free because someone's already done the work, for your particular use case and stack.
If you're up for it, I'd love to chat and see if Hasura could've worked in your case[1]! Especially on the read side, if we're able to model the authz with Hasura your API consumers get a rich read API "for free" and Hasura can delegate the CUD stuff to your existing REST APIs.
Hasura aside, GraphQL will save your API consumers time more than anything else. Like the other comment/reply to this, you still have to build a GraphQL server.
GraphQL by itself won't save you time, and might even increase it (it's a huge buy-in). You'd still have to implement the logic for those 4 endpoints, except now in a more complicated system.
In contrast, tools like Hasura and Postgraphile can potentially save you time because they generate the GraphQL part for you. Then you only need to handle the authN/authZ parts – in theory, at least.
Tangentially related: As a side project, I've been building a backen-as-a-servive platform with a GQL interface derived from the data model and business logic.
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
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.
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)
Writes (mutations) are delegated to a REST endpoint, the GraphQL mutation response can be synchronously (blocking mutation) or asynchronously consumed (mutation + subscription).
I gave it a try, to be honest, I feel it too cumbersone, I expected it to use already available mutations not just copying existing types.
What I really want/need is custom logic that run IN the resolvers of already available query/mutations with the request as input and the possibility to either return an error or modify the payload before it hit the database
but I know is still in preview, will check it again when released
Related, How does one receive a webhook in Hasura? Say I need to take some action on a Stripe rest webhook. All the docs show sending events somewhere, how about receiving and transforming data from 3rd parties?
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.
Stitch looks cool, first time I'm seeing it (long-time happy mongo user via rails/mongoid). Is there a self-hosted version I could hook up to an existing app?
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).
When I tried them a few weeks back to compare, Hasura provided a nice interface, but has a lot going on itself (managing relationships on its own, some Auth stuff on its own) and its own tooling. Postgraphile relies more on postgres, it embeds it’s configuration in comments (or external to the dB). Both had difficulties with complex relationships and introspection across schema boundaries (I want a schema to house my data, and views in a separate schema that are accessed by the API tool). Both felt like I could configure this problem away, hasura wanted me to use their interface to do it, postgraphile wanted me to learn magic comments to attach to tables/columns etc (again, to tell a view that the table it’s drawing from has a relationship with another table).
PostGrest has none of these problems, but/and no graphql. It’s where I landed.
Also, check out dbmate for agnostic rollback management. All it needs is a way to template the sql and I’ll be happier. Some folks using Postgrest use Alembic and SQL Alchemy to build/manage migrations—I’m not sure where I sit on that yet.
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).
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
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!
If you love hasura and want something like firebase, please check out the tutorial with hasura + RxDB. It is like having a firebase with better offline-first and more features and of course without vendor lock-in.
What I liked with Firebase was how easy and fast everything was. One-click create a new project and everything was ready to use.
It's this developer experience I want to mimic with Nhost. By providing a managed backend with simple to use js-sdk (https://github.com/nhost/nhost-js-sdk).
I'm a web entrepreneur and for my project i've been using Parse server project (1) implementation by Back4app (2).
For the non initiated, Parse server is a API server module for Node/Express + mongo + websocket and stuff you need to run a commercial app like auth, role management et all.
We chose this because :
1.Open source (no vendor locking although now i'm sure if i had to move from b4a it would be a small PITA
2. Ready to use
3. actively maintained (graphQL have been implemented although we have not used it yet) (3)
My question is : should i invest time on discovering nhost for my next POC ?
Yes I agree with you. With Hasura there are 3 main ways to handle business logic. We use the first one at Nhost and it's working (and scale) very well.
I know Hasura is actively working on this exact issue and they just released Actions (second option) and I think we will start to see a standard/best practice approach to business logic soon.
Hasura has this feature, but unfortunately it seems like its part of their "pro/enterprise" offering and not the OS version. https://hasura.io/hasura-pro
I'm sorry that we are not doing a better job marketing Nhost. We have been very focused on the product but we hope to get the word out better in the future. Because you are not alone. There are lots of developers with the same problem, that just want things to work.
Hopefully, we will be mentioned in the documentation for Hasura.
Hasura does provide a hosted version (EDIT: not a hosted version) (Hasura Pro). You can read more about it here: https://hasura.io/hasura-pro
1. We're working on adding nhost to the Hasura docs as a deployment guide for when you'd like authn + files + hosted postgres in one neat place. Johan just did a slick demo in the community call right now :)
2. To clarify: Hasura Pro is not a hosted version of Hasura. It's an agent that is added to wherever Hasura happens to be running for enabling monitoring/testing features.
i have heard (from multiple founders in the space) that the hosted db business is a difficult one to be in. see for reference graphcool's switch to prisma.
i suspect that mainly applies to venture backed businesses - it could be a great lifestyle biz
@elithan this looks awesome man. The one thing keeping me in the firebase ecosystem is the firestore rules (basically quick CRUD permissions). Does nhost provide something similar?
I'm reading through the docs now. They are pretty good! I assume I could just use say Apollo on the client? Maybe that part of the docs could use some additional info.
Hi elitan -- since you asked, let me throw out my two cents.
I'm comparing you to Heroku, sorry if that's not your ideal comparison.
I think you need some different price points; the $4/month is great to get started, but the $40/month with 15M just really pales in comparison with Heroku's $50/month for 64G... particularly when I compare it with your $139/month for 5G of database.
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.
I'm considering trying Hasura (or preferably something that can run on SQL Server as that's what we use in production. For me it feels as if trying to do the entire app through Hasura is the wrong approach. But, if we apply CQRS and treat reads different than writes then if we just use it for all of the reads in the system it could eliminate a tonne of code for us. The transactional code can still all go through entity framework and rest APIs.
Firebase user here. I love Firebase because it offers so many components that (usually) play well together: Databases, Authentication, Machine Learning, Storage, Crash Reporting, Analytics, Messaging etc.
Early nhost user here! Elitan's platform is a great way to get started quickly with Hasura, and he was also fantastic with helping me out on some then-undocumented components. Always grateful when a developer takes time to do a 1:1 call.
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
The point made was, software is supposed to solve a problem. Not create a new problem and provide a paid solution. Kinda speaks the truth that something is fundamental isn't made simple yet.
GraphQL definitely has its warts, but it provides more flexibility on the API response than you'd get with ReST, so you're neither sending the whole world to keep your API space small nor adding new endpoints to handle each new client use case. But, GraphQL doesn't fundamentally change the fact that something needs to be responsible for enforcing access restrictions and talking to a database.
Hasura is working to simplify that layer, but developers aren't cheap and I'd imagine the work isn't terribly fun. A lot of existing web frameworks have sprung up out of consultancies to support that development cost. Raising capital is just another funding strategy.
>GraphQL doesn't fundamentally change the fact that something needs to be responsible for enforcing access restrictions and talking to a database.
This is what I'm struggling with when it comes to weighing the pros and cons of GraphQL. I like the SQL model, ie pushing selects and joins and such to the DB, so why not from client to host too? But when you still need to enforce access restriction and such per user per action, how much time would it save me, really?
Seems great for internal apis or prototyping though.
While doable, you probably don't really want a web client talking directly to your RDBMS, if for no other reason than connection management would be a nightmare. The calculus there might be different if using something like DynamoDB, but I suspect you'd still find it challenging to be littering your code with DynamoDB calls. So, at some point you'd build your own little utility classes to abstract away the DB interaction, much like an ORM, and eventually it'll evolve into something with overlapping functionality of GraphQL.
If you accept that you don't want your web client talking directly to the database, then you need something that will interface with the database. That problem has been around for a while with many different solutions: SOAP, ReST, PouchDB/CouchDB, interface with various cloud services, something completely custom, and many others. GraphQL is just one of the latest solutions to that problem and with it, brings some advantages around flexibility in the API requests and responses. It also makes it easy to stitch together multiple GraphQL APIs. So, by being standardized* you don't need to develop the client code yourself and you gain the ability to pull together APIs from multiple sources to present as a single end-point. The most popular clients also provide caching mechanisms so you don't have to keep whacking the back-end for the same data repeatedly. There's also graphiql [1], which gives you a really nice way to query or modify your data on any GraphQL API, which I've found to be very helpful when learning new APIs.
So far, I've found GraphQL most useful for single page applications where the back-end really doesn't have to do much more than handle DB interactions. If you already have an application up and running with little churn in the API, adopting GraphQL probably wouldn't gain you much. In a greenfield application, I was able to use Hasura to replace a simple Rails CRUD application and that was handy. Hasura also takes care of JWT handling, so I could do my auth with Auth0 and not handle that in Rails either. I think GraphQL solves an interesting part of the serverless puzzle.
Don't get me wrong, GraphQL can be downright frustrating at times. Or at least the popular implementations of it can be. We use Relay at work and while it solves a lot of problems, it introduces many of its own that have cost me hours of frustration. I tried using AWS Amplify on a side project, and having to write new AppSync resolvers with Velocity templates is just not pretty. It really took using Hasura for me to finally be sold on what the GraphQL promise could be (side note: Hasura doesn't support the Relay protocol, so if that's important to you, you'll need to find a different tool).
* -- Standardized is a loose term. There is a GraphQL spec, but it leaves a lot available to implementation details. So, then there are other specs, such as Relay, built on top of that. Or de facto standards based on what the popular clients provide.
Hasura and Postgraphile both use row level security for access restriction. Anyone can still execute a query, but they won't get back data they don't have access to.
As per the article, Hasura is focused on PostgreSQL now. They want to provide a similar experience for other databases also So that they can tap into multiple enterprise customers. Also, I think they are working on features to expose different REST APIs via unified GraphQL API.
It's a big enough problem space I think and it has lot of scope for innovation. Enterprise Integration is also quite a big market, so there is definitely an opportunity to create a profitable company there.
To be fair, some of those are full database engines; they have lots of inherent complexity to tackle.
Hasura provides an interface to a database(/s) engine. GraphQL was supposed to solve the interface problem but it looks like it has created a lot of accidental complexity to tackle.
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.
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
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.
Apollo is more than just GraphQL -- it has built-in caching, and gives you booleans for loading state, and more. If you were to roll your own wrapper around window.fetch, for a simpler facade to work with (when making network requests in React), you'd end up with something like Apollo's interface. And that really useful API surface has nothing to do with GraphQL as a specification.
I used to roll all of this stuff from Redux, with actions, reducers, the whole 9 yards. Apollo let me gut all of that-- since I was only using Redux to store data retrieved over the network. Now I'm not hear to preach Apollo specifically, but it's the only client I've worked with, and I can achieve higher productivity with it than working a lower level.
Hasura is more than just GraphQL. It maps GraphQL queries to single SQL statements. So you can think of it more as an ORM, but rather than mapping objects to the database it maps GraphQL statements.
The advantage of this over a traditional ORM is that by having the entire query up front it can be smarter about how it does the translation.
Regarding REST, this is very very different. With REST, you map a single "query," the REST endpoint, to an SQL statement (ideally one). But if you want some other query, you're out of luck. Either you make a new REST endpoint, or you manually call several endpoints and compose the data.
There are some dangers to the GraphQL to SQL approach, namely it's harder to guarantee performance when the client can execute arbitrary queries.
Now, GraphQL by itself, I agree it doesn't solve the hardest problems: getting the data for the query and doing it security. But something like Hasura does address those points and I do think it is an advancement over previous technologies.
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.
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!
- 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!
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.
That was my conclusion looking at them both last year. Hasura had an amazing first-time UX, but postgraphile felt like it was built with production concerns in mind (testing, integrating with larger codebases, easy to add custom or wrap generated CRUD resolvers in js/ts). The most off-putting thing to me, at the time, was that Hasura's solution for auth was to spin up a separate auth service. I prefer a flexible monolith for anything with less than 10 devs working on it. Looks like postgraphile has started paying attention to the first-time UX, but still not as friendly as Hasura's: https://github.com/graphile/starter
Both feel kind of limited by forcing you to encode a ton of logic in SQL which must be migrated vs a mongoid model you can just tweak and commit, but I guess I'm old school and what's old is new again.
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.
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.
Yes, please say more. I've been idly looking that these both from a distance and I would not have expected differences along that dimension. I would expect the expose nearly identical GQL types from the same pg schema.
Wow that's interesting! I chose Postgraphile exactly for this reason: because it lets me customize the schema to a degree that looks just as if I had written it by hand. I found the schema created by Hasura incredibly verbose.
I've always been a huge fan of the Graphile (aka postgraphile) approach. It's just an open-source library, that you can run as a binary when you're just getting started. But when you start getting deep in production territory, it's extensively pluggable and you can gradually swap everything out for your own code, contribute/fork if you need (it's just TS), etc. Full control.
I love the Hasura folks too, and they're a funded startup rather than a one-person operation relying on donations. Open source is hard, and benjie (creator of graphile and many other things, he's incredible) could use some help: https://www.patreon.com/benjie
I made the same evaluation 2 months ago and came to the same decision.
But in my case it was because my existing database is a fairly complicated beast with a lot of updating through stored procedures on views. Hasura wanted to have control of what is happening in the database and there was zero chance that it would agree with the existing triggers about what should happen or how it worked. (Example of an issue, Hasura wants to own the view and view structure so that it can make real time subscriptions work.)
By contrast Postgraphile was happy to be pointed at a schema of views for just what it should see, read a https://www.graphile.org/postgraphile/smart-tags-file/ and believe what it was told there about the underlying database structure, and then expose an API that showed what I wanted it to show without breaking what was under the hood.
> But in my case it was because my existing database is a fairly complicated beast with a lot of updating through stored procedures on views. Hasura wanted to have control of what is happening in the database and there was zero chance that it would agree with the existing triggers about what should happen or how it worked. (Example of an issue, Hasura wants to own the view and view structure so that it can make real time subscriptions work.)
Unless I’m grossly misunderstanding, none of that is correct in the slightest!
Hasura doesn’t assume _anything_ about your table or view structure. Hasura will never interfere with your existing stored procedures either. At most hasura will refuse to track some items in your schema because they don’t adhere to the GraphQL naming spec. But hasura doesn’t own and control tables/views/triggers at all!
I’m actually really confused and surprised because this sounds exactly like the opposite of what Hasura does and what it was designed for, ie work with existing databases instantly.
I’d love to understand this in more detail and see if there was actually an issue and what it was. It's an important thing for us to look into and fix and would deeply appreciate your notes! Is there someway i can reach you?
Anyways here is the use case. We have a table named model.nodes. We have various model.foo_detail tables. And views named model.foo. Every foo is a node. (Clearly this schema predates our interest in GraphQL...) We have triggers on the foos so that they can update the underlying combinations of tables correctly, and also keep an audit log. We have an external CMS running off of a different architecture which handles authentication.
There are additional complications that I am not going into, such as the fact that every client installation will have new, client specific tables, in a client specific schema.
We wanted to have all of the _detail tables hidden. To choose what to expose. To rename some things here and there. To lift the foreign key relationships from foo_details to the exposed foo. To have all authorization handled by the application that already handles it. To allow subscriptions to root objects with as little overhead as possible. To add custom pub-sub channels that were also available for customers. To have a client installation include client specific tables (albeit with a bit of renaming to guarantee no conflicts between what the client has and anything we ever will have in our core product). And to make it easy to maintain it going forward.
3 of us independently looked at all the available tools. We independently came to the same conclusion. The two most mature products were Hasura and Postgraphile. Hasura on our database presented an interface that was nothing like what we wanted to show, and we didn't see how to customize to be what we wanted. Postgraphile did a better job out of the box, and we could see how to make it give us exactly what we wanted. (Yes, we had to do things like add pg_notify statements to our stored procedures, but it was straightforward.)
And yes, the language mattered. For example neither Hasura nor Postgraphile offers an out of the box integration with the random CMS we were dealing with. But none of us know Haskell, all of us know JavaScript, and Postgraphile is not hard to integrate with passport.js. And through that we can do anything that we want.
There is an old programming rule. "Only one person gets to be clever at a time." We were already dealing with a database schema with a lot of cleverness built in. Hasura has a lot of cleverness as well. You are right that Hasura didn't want to actually control* our database, but we broke its expectations pretty badly and would have to modify it pretty extensively to make it work like we wanted.
I've been working on GraphQL services since 2015. I worked on the design of the precursor to postgraphile; it was called postgraphql. Hadn't heard of Hasura before today, but it looks interesting.
The primary complaints I hear from others about GraphQL are observability and the learning curve for devs who are new to it. I think these projects add a lot of value with tools like the GraphQL playground (similar to GraphiQL but better), middleware extensibility for observation/analytics, their documentation, and most importantly the starter/boilerplate projects.
IMO, the preferred option today is Prisma. They have a non-production-ready v2 that is available for testing. But even v1 is good for an enterprise product; and they're working on migration/codemod to get onto v2 when it's ready.
But the other big piece of the puzzle is deciding on a GraphQL client. It seems like most choose Apollo + Redux, but Relay is, without a doubt in my mind, the better library/framework for consuming GraphQL in the frontend. Facebook designed React, Relay, and GraphQL to work together really nicely. Relay takes some re-learning to think about frontend data dependencies and caching, but it's really well designed.
I think GraphQL on its own has value as a centralized contract between frontend and backend services, and is a nice query and mutation language; but without Relay I don't think you get the full benefits of all the hard work that goes into the GraphQL service design. And teams/organizations that end up with Apollo/Redux designs suffer from complexities around cache management that Relay does a better job of reducing.
Curious if you were active on the precursor to postgraphile why you feel Prisma is a better option. It's been my experience as well, but would love to hear what the deciding factors were for you.
Postgraphile is more open-ended and advanced, which could be better for some cases. I really like it and enjoy writing the PostgreSQL directly. Prisma compresses the domain a little more than Postgraphile, which means its a little simpler.
The Prisma datamodel very closely mirrors the GraphQL schema. It has just a bare minimum variance to allow different data types (and maybe something else I'm forgetting). I think the generated GraphQL for the database client ends up being simpler and easier to debug; but that's just my feeling about it.
The Prisma database admin tool at `host:port/_admin` is nice; and compliments the GraphQL Playground really well. Prisma develops GraphQL Playground as an open-source project, inspired by GraphiQL which comes out-of-the-box with graphql-server.
Curious to know what you think of the React + RPC (e.g. https://github.com/reframejs/wildcard-api) + PostgreSQL stack in comparison to React + Relay + GraphQL + PostgreSQL?
RPC tightly couples frontend and backend. Decoupling is usually only needed for (very) large applications; while getting there you migrate from RPC to GraphQL.
It looks like a nice library. It might be good as a learning tool. I'm not sure what kind of use-case I would want it for, maybe a small game? It looks similar to how I've done smaller/demo/mock-up APIs for frontend apps. I like the simplicity.
I think if I was going to be deploying a real database (PostgreSQL), I'd want to do things with authorization and network configuration; at which point I'd be dealing with enough stuff around the user profile that I'd want my preferred query and mutation design (GraphQL + Relay).
If at any point you're going to be fetching data containing long lists, I'd also prefer to be working with GraphQL and Relay because the design is well thought-out for doing filtering, pagination, and caching.
Decoupling is good any time you want to allow different parts to change independently. Migrating architectures can take a significant amount of effort, but it just depends what you want to accomplish.
One way to think about Wildcard (and RPC in general) is that it allows you to directly use SQL queries to retrieve and mutate data for your frontend.
That said, if you prefer using Relay + GraphQL over writing SQL queries, then Wildcard (and RPC) may not be the right tool for you. Although I'd worry about the complexity of your stack. Unnecessary complex stacks tend to be an evil time sink in the long run. Simplicity is key.
RPC + PotgreSQL is fundamentally simpler than Relay + GraphQL + Hasura + PotgreSQL.
The thing is that you need GraphQL only when you need to expose your data to third parties.
GraphQL = generic API = thid-party devS.
For consuming your database from your own frontend, you don't need GraphQL and RPC is enough and simpler.
> Decoupling is good any time you want to allow different parts to change independently
With Wildcard(/RPC) you deploy frontend and backend at the same time but you develop both independently.
Migration is easy when you create a GraphQL API in parallel to your existing RPC API and progressively transition from your RPC API to your newly created GraphQL API. That said, chances are high that GraphQL will never be needed; only very large companies need GraphQL (the organization is so large that exposing an API to the whole organization is almost like exposing an API to the whole world). Basically devS of very large companies ~= third-party devS and you then need a generic API such as GraphQL.
I started with Hasura and I implemented it on two business projects. It was a great first step but the lack of customization quickly became an issue. Having the logic split between several services was another big issue (Hasura + firebase auth + serverless functions for any logic). Ultimately it resulted in a slower development speed than what we were doing at my company before using Hasura (custom GraphQL backend development).
Several months ago we switched to Postgraphile, and it solved the issues mentioned above. The plugin system allows us to implement the custom logic in a simple and performant way, whether it's a custom validation on a mutation or tweaking the GraphQL type system. And all the logic is centralized in one project. It's clean, fast and testable.
Another big advantage is that Postgraphile relies on Postgres RLS for permissions, which allows us to manage it using normal SQL migrations. In comparison, we had a lot of pain evolving an existing permission schema on Hasura.
Postgraphile can also automatically expose a Relay compliant schema, supporting Relay connections. It's not possible with Hasura.
Except for pure read-only GraphQL APIs, I strongly recommend looking into Postgraphile over Hasura.
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.
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.
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.
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.
You would never expose your database directly to the whole world.
Either it is an internal service, only consumed by your own products, and then it's fine.
Or you have an API gateway to control who and how your services are queried.
The API Gateway is your interface who should not break.
Your services communicating with your database (through Prisma, Hasura, any ORM, ...) can and will break.
When you base your GraphQL schema on your database schema for your internal services, you get rid of one long and annoying step of putting glue everywhere. This is especially true in a microservice architecture, and even more in the corporate world where you are expected to produce code quickly.
> 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.
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.
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/
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.
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.
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).
With Hasura, you can create arbitrary roles (like admin, manager, etc) and restrict access to data on the basis of these roles.
These roles can be assigned to a frontend session by generating signed JWTs.
With Postgres RBAC, you'd need something to lift the roles to be consumed by the frontend. With Hasura it works out of the box.
Also, I did consider using Postgraphile, but it was easier to get started with Hasura, so I went ahead with it. I don't have enough info to make a comparison.
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.
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.
> 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.
the Graphene implementation for Django brings up a Relay GraphQL server so fast. The best part is that at compile time it ensures your GraphQL schema confirms to the Relay standard, enforcing correct naming. You really don't have to think about much.
198 comments
[ 0.29 ms ] story [ 1760 ms ] thread[1]http://postgrest.org/
The scope is smaller than GraphQL, but some of the interesting benefits - like smarter and more optimized requests - are available with PostgREST.
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.
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
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
Here's a reference application I put together: https://github.com/cpursley/react-admin-low-code
Now I just need a way to migrate my data from somewhere else to Hasura.
Would really appreciate it! :)
The advantage is React Admin is back end agnostic and you can tap into the huge React ecosystem. And with Hasura you get automatic GraphQL endpoints (Django nor Rails Active Admin do this - you have to create models first vs just a schema with Hasura) which can be used for more than just your admin backend.
Hasura also ships with websocket support, something that Django has always struggled with.
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.
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.
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.
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!
E.g. https://github.com/reframejs/wildcard-api for JavaScript.
The neat thing about RPC is that you can tap into the full power of PostgreSQL "directly" from the frontend.
The thing has a bunch of complex business and authorization rules. Not to mention a bunch of per-client customization. There's also some neat handling around versioning and copy-on-write type behavior to provide a mix of immutability and space saving.
To me, this is CRUD because: most resources literally have 4 endpoints (create, index, update and delete). We write a ton of tests to cover all the cases. It's time consuming, even tedious, and it's boring / simple compared to the user facing stuff we do.
I've never touched GraphQL, so can that really save me months of work? Or would it save me about as much time as Rails would (which would be not a lot) ?
Its main effect is to move app logic query writing to the frontend, in something that's not SQL, which some folks seem to really like. But it's still got to get turned into whatever your data sources actually speak at some point, just like REST or anything else. If there's nothing magically doing that for you or if the magic turns out to suck, you'll be doing it manually.
[EDIT] to make it more clear, here are your possibilities:
1) a. GraphQL queries -> b. Queries for one or more kinds of datastore
2) a. REST requests -> b. Queries for one or more kinds of datastore
You shift choices about how to query kinda forward in 1, but that means you need a very general and flexible GraphQL query handler to make step 2 happen, and if that doesn't exist or is insufficient you have to write it. That is, obviously, more work than 2, in which 2b is where the choices you'd make in 1a happen, so that layer doesn't need to be as flexible.
TL;DR the apparent flexibility and responsibility-shifting of GraphQL isn't free and is in fact quite expensive (and, if I may, risky)... unless it is free because someone's already done the work, for your particular use case and stack.
Hasura aside, GraphQL will save your API consumers time more than anything else. Like the other comment/reply to this, you still have to build a GraphQL server.
[1] I'm twitter.com/tanmaigo or tanmaig@hasura.io
In contrast, tools like Hasura and Postgraphile can potentially save you time because they generate the GraphQL part for you. Then you only need to handle the authN/authZ parts – in theory, at least.
Posting here as it may be of interest to readers: l https://massiveinference.com
I love Django, but even its amazing ORM has limitations. I can't imagine what it's like to deal with something similar but on the frontend instead...
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
Here's an example for a regex for validating email from one of our community calls: https://youtu.be/-9jX21PKyk0?list=PLTRTpHrUcSB8Dp3hk5SiVNHNP...
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.
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)
Writes (mutations) are delegated to a REST endpoint, the GraphQL mutation response can be synchronously (blocking mutation) or asynchronously consumed (mutation + subscription).
Will give it a try, thanks
What I really want/need is custom logic that run IN the resolvers of already available query/mutations with the request as input and the possibility to either return an error or modify the payload before it hit the database
but I know is still in preview, will check it again when released
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.
(And a way that doesn't require writing rollbacks, which sometimes aren't even possible anyway).
Their migration tool is really nice; reminds me of Rails but better as you can write raw SQL.
https://github.com/hasura/graphql-engine/tree/master/scripts...
PostGrest has none of these problems, but/and no graphql. It’s where I landed.
Also, check out dbmate for agnostic rollback management. All it needs is a way to template the sql and I’ll be happier. Some folks using Postgrest use Alembic and SQL Alchemy to build/manage migrations—I’m not sure where I sit on that yet.
Feel free to check it out: https://github.com/sastraxi/great-bear
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
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.
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
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!
https://hasura.io/blog/building-an-offline-first-web-app-wit...
It's this developer experience I want to mimic with Nhost. By providing a managed backend with simple to use js-sdk (https://github.com/nhost/nhost-js-sdk).
We chose this because :
1.Open source (no vendor locking although now i'm sure if i had to move from b4a it would be a small PITA 2. Ready to use 3. actively maintained (graphQL have been implemented although we have not used it yet) (3)
My question is : should i invest time on discovering nhost for my next POC ?
(1) : https://github.com/parse-community (2) : https://www.back4app.com/ (3) : https://docs.parseplatform.org/graphql/guide/
1. SQL (Thanks PostgreSQL)
2. Instant realtime GraphQL (Thanks Hasura)
3. Zero vendor lock-in
This is wrong. For basic features that are absolutely needed for a real-life app you will need the "Pro" hasura license.
Amazing at first, but quickly fell apart when I had to implement any sort of meaningful business logic.
1. https://3factor.app/
2. Actions - https://hasura.io/docs/1.0/graphql/manual/actions/index.html
3. Remote Schema - https://hasura.nhost.io/console/remote-schemas/manage/schema...
I know Hasura is actively working on this exact issue and they just released Actions (second option) and I think we will start to see a standard/best practice approach to business logic soon.
@elitan - just checking nhost. Features sounds promising.
Did you use hasura for building nhost's backend as well ?
Do you know why Hasura don't provide a managed service themselves?
Also, I wonder if Hasura will eventually move to a MongoDB-like license.
Hopefully, we will be mentioned in the documentation for Hasura.
Hasura does provide a hosted version (EDIT: not a hosted version) (Hasura Pro). You can read more about it here: https://hasura.io/hasura-pro
1. We're working on adding nhost to the Hasura docs as a deployment guide for when you'd like authn + files + hosted postgres in one neat place. Johan just did a slick demo in the community call right now :)
2. To clarify: Hasura Pro is not a hosted version of Hasura. It's an agent that is added to wherever Hasura happens to be running for enabling monitoring/testing features.
i suspect that mainly applies to venture backed businesses - it could be a great lifestyle biz
Together with Nhost's auth system and Hasura, it's easier than Firebase.
https://hasura.io/learn/
I'm comparing you to Heroku, sorry if that's not your ideal comparison.
I think you need some different price points; the $4/month is great to get started, but the $40/month with 15M just really pales in comparison with Heroku's $50/month for 64G... particularly when I compare it with your $139/month for 5G of database.
Thanks for a great looking product, though!
How do we add business logic ?
Folks @hasura, where do we learn about haskell ? any helpful pointers much appreciated.
1. Actions - https://hasura.io/docs/1.0/graphql/manual/actions/index.html
2. https://3factor.app/
3. Remote schemas - https://hasura.io/docs/1.0/graphql/manual/remote-schemas/ind...
Awkwardly. Good luck
Check out the result here: http://www.hedgecheap.com
Which parts of Firebase is Nhost replacing?
Next on the road map: Cloud Functions, Hosting, Crash Reporting.
We try to go from the core and outwards. Hope it makes sense.
Thanks again!
https://www.moesif.com/blog/graphql/technical/Ways-To-Add-Gr...
Hasura is working to simplify that layer, but developers aren't cheap and I'd imagine the work isn't terribly fun. A lot of existing web frameworks have sprung up out of consultancies to support that development cost. Raising capital is just another funding strategy.
This is what I'm struggling with when it comes to weighing the pros and cons of GraphQL. I like the SQL model, ie pushing selects and joins and such to the DB, so why not from client to host too? But when you still need to enforce access restriction and such per user per action, how much time would it save me, really?
Seems great for internal apis or prototyping though.
If you accept that you don't want your web client talking directly to the database, then you need something that will interface with the database. That problem has been around for a while with many different solutions: SOAP, ReST, PouchDB/CouchDB, interface with various cloud services, something completely custom, and many others. GraphQL is just one of the latest solutions to that problem and with it, brings some advantages around flexibility in the API requests and responses. It also makes it easy to stitch together multiple GraphQL APIs. So, by being standardized* you don't need to develop the client code yourself and you gain the ability to pull together APIs from multiple sources to present as a single end-point. The most popular clients also provide caching mechanisms so you don't have to keep whacking the back-end for the same data repeatedly. There's also graphiql [1], which gives you a really nice way to query or modify your data on any GraphQL API, which I've found to be very helpful when learning new APIs.
So far, I've found GraphQL most useful for single page applications where the back-end really doesn't have to do much more than handle DB interactions. If you already have an application up and running with little churn in the API, adopting GraphQL probably wouldn't gain you much. In a greenfield application, I was able to use Hasura to replace a simple Rails CRUD application and that was handy. Hasura also takes care of JWT handling, so I could do my auth with Auth0 and not handle that in Rails either. I think GraphQL solves an interesting part of the serverless puzzle.
Don't get me wrong, GraphQL can be downright frustrating at times. Or at least the popular implementations of it can be. We use Relay at work and while it solves a lot of problems, it introduces many of its own that have cost me hours of frustration. I tried using AWS Amplify on a side project, and having to write new AppSync resolvers with Velocity templates is just not pretty. It really took using Hasura for me to finally be sold on what the GraphQL promise could be (side note: Hasura doesn't support the Relay protocol, so if that's important to you, you'll need to find a different tool).
* -- Standardized is a loose term. There is a GraphQL spec, but it leaves a lot available to implementation details. So, then there are other specs, such as Relay, built on top of that. Or de facto standards based on what the popular clients provide.
[1] -- https://github.com/graphql/graphiql
It's a big enough problem space I think and it has lot of scope for innovation. Enterprise Integration is also quite a big market, so there is definitely an opportunity to create a profitable company there.
Hasura provides an interface to a database(/s) engine. GraphQL was supposed to solve the interface problem but it looks like it has created a lot of accidental complexity to tackle.
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.
What library are you using to generate the types?
This is the thing Hasura (and Postgraphile) is trying to make go away. From my limited experience with Hasura, it works pretty well.
I used to roll all of this stuff from Redux, with actions, reducers, the whole 9 yards. Apollo let me gut all of that-- since I was only using Redux to store data retrieved over the network. Now I'm not hear to preach Apollo specifically, but it's the only client I've worked with, and I can achieve higher productivity with it than working a lower level.
The advantage of this over a traditional ORM is that by having the entire query up front it can be smarter about how it does the translation.
Regarding REST, this is very very different. With REST, you map a single "query," the REST endpoint, to an SQL statement (ideally one). But if you want some other query, you're out of luck. Either you make a new REST endpoint, or you manually call several endpoints and compose the data.
There are some dangers to the GraphQL to SQL approach, namely it's harder to guarantee performance when the client can execute arbitrary queries.
Now, GraphQL by itself, I agree it doesn't solve the hardest problems: getting the data for the query and doing it security. But something like Hasura does address those points and I do think it is an advancement over previous technologies.
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.
We covered a bunch of them here:
https://hasura.io/blog/fluent-graphql-clients-how-to-write-q...
- 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
Do you have any other point to sustain this comment of yours?
> my conclusion is that PostGraphile is way ahead of all this
- 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!
Unless I'm missing something, Hasura is FOSS too.
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!
Both feel kind of limited by forcing you to encode a ton of logic in SQL which must be migrated vs a mongoid model you can just tweak and commit, but I guess I'm old school and what's old is new again.
https://www.graphile.org/postgraphile/
https://hasura.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/prest/prest
https://resthapi.com/
I love the Hasura folks too, and they're a funded startup rather than a one-person operation relying on donations. Open source is hard, and benjie (creator of graphile and many other things, he's incredible) could use some help: https://www.patreon.com/benjie
But in my case it was because my existing database is a fairly complicated beast with a lot of updating through stored procedures on views. Hasura wanted to have control of what is happening in the database and there was zero chance that it would agree with the existing triggers about what should happen or how it worked. (Example of an issue, Hasura wants to own the view and view structure so that it can make real time subscriptions work.)
By contrast Postgraphile was happy to be pointed at a schema of views for just what it should see, read a https://www.graphile.org/postgraphile/smart-tags-file/ and believe what it was told there about the underlying database structure, and then expose an API that showed what I wanted it to show without breaking what was under the hood.
Unless I’m grossly misunderstanding, none of that is correct in the slightest!
Hasura doesn’t assume _anything_ about your table or view structure. Hasura will never interfere with your existing stored procedures either. At most hasura will refuse to track some items in your schema because they don’t adhere to the GraphQL naming spec. But hasura doesn’t own and control tables/views/triggers at all!
I’m actually really confused and surprised because this sounds exactly like the opposite of what Hasura does and what it was designed for, ie work with existing databases instantly.
I’d love to understand this in more detail and see if there was actually an issue and what it was. It's an important thing for us to look into and fix and would deeply appreciate your notes! Is there someway i can reach you?
Anyways here is the use case. We have a table named model.nodes. We have various model.foo_detail tables. And views named model.foo. Every foo is a node. (Clearly this schema predates our interest in GraphQL...) We have triggers on the foos so that they can update the underlying combinations of tables correctly, and also keep an audit log. We have an external CMS running off of a different architecture which handles authentication.
There are additional complications that I am not going into, such as the fact that every client installation will have new, client specific tables, in a client specific schema.
We wanted to have all of the _detail tables hidden. To choose what to expose. To rename some things here and there. To lift the foreign key relationships from foo_details to the exposed foo. To have all authorization handled by the application that already handles it. To allow subscriptions to root objects with as little overhead as possible. To add custom pub-sub channels that were also available for customers. To have a client installation include client specific tables (albeit with a bit of renaming to guarantee no conflicts between what the client has and anything we ever will have in our core product). And to make it easy to maintain it going forward.
3 of us independently looked at all the available tools. We independently came to the same conclusion. The two most mature products were Hasura and Postgraphile. Hasura on our database presented an interface that was nothing like what we wanted to show, and we didn't see how to customize to be what we wanted. Postgraphile did a better job out of the box, and we could see how to make it give us exactly what we wanted. (Yes, we had to do things like add pg_notify statements to our stored procedures, but it was straightforward.)
And yes, the language mattered. For example neither Hasura nor Postgraphile offers an out of the box integration with the random CMS we were dealing with. But none of us know Haskell, all of us know JavaScript, and Postgraphile is not hard to integrate with passport.js. And through that we can do anything that we want.
There is an old programming rule. "Only one person gets to be clever at a time." We were already dealing with a database schema with a lot of cleverness built in. Hasura has a lot of cleverness as well. You are right that Hasura didn't want to actually control* our database, but we broke its expectations pretty badly and would have to modify it pretty extensively to make it work like we wanted.
The primary complaints I hear from others about GraphQL are observability and the learning curve for devs who are new to it. I think these projects add a lot of value with tools like the GraphQL playground (similar to GraphiQL but better), middleware extensibility for observation/analytics, their documentation, and most importantly the starter/boilerplate projects.
IMO, the preferred option today is Prisma. They have a non-production-ready v2 that is available for testing. But even v1 is good for an enterprise product; and they're working on migration/codemod to get onto v2 when it's ready.
But the other big piece of the puzzle is deciding on a GraphQL client. It seems like most choose Apollo + Redux, but Relay is, without a doubt in my mind, the better library/framework for consuming GraphQL in the frontend. Facebook designed React, Relay, and GraphQL to work together really nicely. Relay takes some re-learning to think about frontend data dependencies and caching, but it's really well designed.
I think GraphQL on its own has value as a centralized contract between frontend and backend services, and is a nice query and mutation language; but without Relay I don't think you get the full benefits of all the hard work that goes into the GraphQL service design. And teams/organizations that end up with Apollo/Redux designs suffer from complexities around cache management that Relay does a better job of reducing.
The Prisma datamodel very closely mirrors the GraphQL schema. It has just a bare minimum variance to allow different data types (and maybe something else I'm forgetting). I think the generated GraphQL for the database client ends up being simpler and easier to debug; but that's just my feeling about it.
The Prisma database admin tool at `host:port/_admin` is nice; and compliments the GraphQL Playground really well. Prisma develops GraphQL Playground as an open-source project, inspired by GraphiQL which comes out-of-the-box with graphql-server.
RPC tightly couples frontend and backend. Decoupling is usually only needed for (very) large applications; while getting there you migrate from RPC to GraphQL.
I think if I was going to be deploying a real database (PostgreSQL), I'd want to do things with authorization and network configuration; at which point I'd be dealing with enough stuff around the user profile that I'd want my preferred query and mutation design (GraphQL + Relay).
If at any point you're going to be fetching data containing long lists, I'd also prefer to be working with GraphQL and Relay because the design is well thought-out for doing filtering, pagination, and caching.
Decoupling is good any time you want to allow different parts to change independently. Migrating architectures can take a significant amount of effort, but it just depends what you want to accomplish.
That said, if you prefer using Relay + GraphQL over writing SQL queries, then Wildcard (and RPC) may not be the right tool for you. Although I'd worry about the complexity of your stack. Unnecessary complex stacks tend to be an evil time sink in the long run. Simplicity is key.
RPC + PotgreSQL is fundamentally simpler than Relay + GraphQL + Hasura + PotgreSQL.
The thing is that you need GraphQL only when you need to expose your data to third parties.
GraphQL = generic API = thid-party devS.
For consuming your database from your own frontend, you don't need GraphQL and RPC is enough and simpler.
> Decoupling is good any time you want to allow different parts to change independently
With Wildcard(/RPC) you deploy frontend and backend at the same time but you develop both independently.
Migration is easy when you create a GraphQL API in parallel to your existing RPC API and progressively transition from your RPC API to your newly created GraphQL API. That said, chances are high that GraphQL will never be needed; only very large companies need GraphQL (the organization is so large that exposing an API to the whole organization is almost like exposing an API to the whole world). Basically devS of very large companies ~= third-party devS and you then need a generic API such as GraphQL.
(shameless plug)
Several months ago we switched to Postgraphile, and it solved the issues mentioned above. The plugin system allows us to implement the custom logic in a simple and performant way, whether it's a custom validation on a mutation or tweaking the GraphQL type system. And all the logic is centralized in one project. It's clean, fast and testable.
Another big advantage is that Postgraphile relies on Postgres RLS for permissions, which allows us to manage it using normal SQL migrations. In comparison, we had a lot of pain evolving an existing permission schema on Hasura.
Postgraphile can also automatically expose a Relay compliant schema, supporting Relay connections. It's not possible with Hasura.
Except for pure read-only GraphQL APIs, I strongly recommend looking into Postgraphile over Hasura.
https://www.apollographql.com/
https://translate.google.com/#view=home&op=translate&sl=el&t...
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.
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/
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.
Isn't the point of GraphQL to decouple your interface (who should not break) from your backend implementation details?
Either it is an internal service, only consumed by your own products, and then it's fine. Or you have an API gateway to control who and how your services are queried.
The API Gateway is your interface who should not break. Your services communicating with your database (through Prisma, Hasura, any ORM, ...) can and will break.
When you base your GraphQL schema on your database schema for your internal services, you get rid of one long and annoying step of putting glue everywhere. This is especially true in a microservice architecture, and even more in the corporate world where you are expected to produce code quickly.
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
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.
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.
These roles can be assigned to a frontend session by generating signed JWTs.
With Postgres RBAC, you'd need something to lift the roles to be consumed by the frontend. With Hasura it works out of the box.
Also, I did consider using Postgraphile, but it was easier to get started with Hasura, so I went ahead with it. I don't have enough info to make a comparison.
Congrats to the folks at hasura for the raise, long live postgres and graphql.
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.
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.
the Graphene implementation for Django brings up a Relay GraphQL server so fast. The best part is that at compile time it ensures your GraphQL schema confirms to the Relay standard, enforcing correct naming. You really don't have to think about much.