PS: as a sidenote and since i'm sure you'll get the question a lot : when i saw it was coded in haskell i was a bit nervous, but at the same time a bit more confident this wasn't another junior-level spaghetti code base.
We're also planning to release a lot of cool GraphQL OSS stuff for the haskell community because of our work over the last year.
The primary difference is how authorization is handled. In Postgraphile, you map your application roles to Postgres users and define policies using Postgres's RLS. With Hasura, you define rules on roles (similar to Postgres's RLS) but it integrates into your existing auth system using webhooks.
[1] https://docs.hasura.io/1.0/graphql/manual/auth/index.html
Another deployment pattern is to make everything go through an API gateway which would usually do the auth resolution for all microservices, and thus can set the dynamic variables required for access control for HGE directly too. In this case, auth-webhook is disabled.
Hasura and Prisma have very different approaches and end-goals at the moment.
TL;DR: Very simply put, Hasura is postgres first and adds an access-control layer to make it possible to query from the front end directly.
The longer version:
Prisma is intended to be a GraphQL ORM to Postgres (and several other databases with a common API) whereas Hasura is more database first and intended to let you leverage Postgres features over GraphQL.
Hasura comes with and lets you use any postgres migration system and then gives you GraphQL on top of it. This is what allows Hasura to give you GraphQL over any existing Postgres database and application even.
Hasura also comes with an optional access-control layer that makes it feasible to be used by frontend clients directly. This access control is inspired from postgres's RLS but does not depend on or use postgres RLS and can be coupled with application logic/auth.
Sorry to be hijacking this thread, but how would you say Prisma compares to something like Graphene (with an appropriate ORM adapter). I've only used Graphene with Python and the SQLAlchemy adapter, but it sounds pretty similar? Is Prisma typically used as the only ORM in project, or is it used in conjunction with some other ORM?
You should think of Prisma as the data layer for your applications. If you look at large tech companies who are typically ahead of the status quo for how to build applications, then you see that there is a trend to move away from traditional ORMs.
Twitter has a service called Strato that manages data access for all their services. Facebook has TAO that serves a similar role. Prisma is an open source implementation of that pattern.
If you are building a GraphQL API using for example Graphene, then you could use Prisma as your data layer, but Prisma can also be used in non-GraphQL applications. If you are using the Nodejs implementation, then you can take advantage of schema delegation to simplify the implementation of your resolvers. The GraphQL ecosystem is still evolving, so these capabilities will come to more languages in the future.
So in short - Prisma replaces SQLAlchemy, not Graphene. Hope that provides some clarity :-)
As you work at Hasura I assume you are aware that Prisma does work with existing postgres databases. You can look up the documentation for introspecting an existing database at https://www.prisma.io/docs/reference/service-configuration/d...
Full disclosure - I am the co-founder of Prisma.
This is a standalone service that gives you GraphQL on Postgres. It comes with fine-grained access control that can integrate with any auth provider. It can also work with any existing postgres database as is, and allows you to expose select tables/views across your postgres schemas over GraphQL.
Looking forward to your feedback!