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