2 ms·

It all depends on whether you expect to 1) use GraphQL as an ORM replacement or 2) use GraphQL as a layer to aggregate multiple disparate services into a unifie

It all depends on whether you expect to 1) use GraphQL as an ORM replacement or 2) use GraphQL as a layer to aggregate multiple disparate services into a unified API. Most people want #1, Graphene is a bad choice because you still have to write a lot of boilerplate code. It has the added benefit that the current process is responsible for parsing the GraphQL query and directly calling the database, vs. using something like Prisma/Hasura which (may) require a separate process which in turn calls your database (so 2 network hops). GraphQL was never intended to be an ORM replacement, but many have steered it towards that direction. It's not a bad thing, but it's still the same level of abstraction and confusion that people have wrestled with when using traditional ORM's except now you're introducing a different query API vs. native code/fluent interfaces/SQL.

tango12 6y ago
(I'm from Hasura) While Hasura + GraphQL can be used as an ORM (especially for serverless functions!), Hasura is designed to be used directly by clients as well. Hasura has a metadata configuration system that works on top of an existing database that allows configuring mapping, relationships and most importantly permissions that make the GraphQL feasible to be used by even frontend apps. [1] Further, Hasura has remote joins that can "join" across Postgres, GraphQL, REST sources and secure them. [2] [1] https://hasura.io/blog/hasura-authorization-system-through-examples/ https://hasura.io/blog/hasura-authorization-system-through-e... [2]: https://hasura.io/blog/remote-joins-a-graphql-api-to-join-database-and-other-data-sources/ https://hasura.io/blog/remote-joins-a-graphql-api-to-join-da...