Hacker News new | ask | show | jobs
by vsurabhi 2894 days ago
Hi, I'm one of the core contributors to the project.

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.

1 comments

> Prisma is intended to be a GraphQL ORM to Postgres

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?

Happy to provide a more thorough answer :-)

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 :-)

I think you should be able to use it alongside SQLAlchemy if you manage your schema through Prisma. Someone from Prisma team should be able to give you a more thorough answer.