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.
