3 ms·

GraphQL is really nice for the client. But I have an hard time believing that this flexibility given to the client (over well defined REST endpoints for example

GraphQL is really nice for the client. But I have an hard time believing that this flexibility given to the client (over well defined REST endpoints for example) doesn't hardly impact the complexity of the queries to make to the database! How it is possible for a product like Prisma/Hasura to be able to generate the complex logic of the queries required to handle real world logic and support that extra client flexibility? In my experience even regular SQL ORMs are often a bottleneck in a REST application and you need to fallback to (or only use) plain SQL. And even if you can fallback to hand written SQL in those GraphQL backends (I hope so!), the extra complexity of the queries to make is still there because of GraphQL.

zackify 8y ago
With dataloading, you can turn anything that would need to be a join into two queries, using whereIns. It just takes a little extra work. I wrote a blog post on this exact issue a while back. https://zach.codes/graphql-query-batching-solutions/ https://zach.codes/graphql-query-batching-solutions/
- zbentley 8y ago
  > With dataloading, you can turn anything that would need to be a join into two queries *two queries and a lot of extra memory consumption.
- jonnydubowsky 8y ago
  Great post! Very helpful thanks
ThePhysicist 8y ago
I think Hasura takes care of building „good“ SQL queries that retrieve the data in a single request. I agree that it’s often not viable to resort to the standard GraphQL resolvers that will produce n database queries when asking for a list of items with a corresponding joined field. A while ago I built a MongoDB->SQL wrapper that would take a MongoDB query (with arbitrary many nested $include entries) and convert it to a single SQL query, which worked quite well. Of course this didn’t have any logic to check for permissions as we weren’t “crazy” enough to let arbitrary clients formulate the queries (we did it in the backend). The code is available at https://github.com/adewes/blitzdb https://github.com/adewes/blitzdb, we used it with https://github.com/QuantifiedCode/QuantifiedCode https://github.com/QuantifiedCode/QuantifiedCode.
- tirumaraiselvan 8y ago
  You are right. Instead of writing resolvers for each graphql node, Hasura compiles the graphql query into a single SQL query. Read more here: https://blog.hasura.io/architecture-of-a-high-performance-graphql-to-sql-server-58d9944b8a87 https://blog.hasura.io/architecture-of-a-high-performance-gr... PS: I work for Hasura.
nikolasburk 8y ago
Disclaimer upfront: I work at Prisma.io :) It's very important to properly distinguish Hasura and Prisma (as well as AppSync & Graphcool while we're at it). Hasura, AppSync and Graphcool are all Backends-as-a-Service (basically "Firebase for GraphQL"). You get an instant GraphQL CRUD API with a database and some ways to configure authentication/authorization. This is great for simpler applications but typically comes with limitations when requirements become more complex. Speaking from experience after 2 years of running Graphcool, we've learned from our customers that (especially larger) development teams quickly outgrow the capabilities of a BaaS and need more control and flexibility in their technology stack. This was exactly the reasoning why we've moved to Prisma which now replaces traditional ORMs and makes it easier for developers to build GraphQL servers (but also other applications like REST APIs). Another point is that GraphQL was invented as a query language for APIs, not databases. Exposing a CRUD GraphQL API to client applications was never the purpose of GraphQL - clients should still be able to consume a domain-specific API that's tailored to their needs (you typically don't want to expose all CRUD operations to your clients in a production application). With Prisma, we're trying to create the right abstraction™️ that helps people get started quickly but at the same time Prisma should remain the proper tool for them as their projects scale and grow in complexity.
- vsurabhi 8y ago
  While Hasura is a 'BaaS' (in the sense that it can be directly exposed to frontend applications), it absolutely does not come with the limitations that you have mentioned. Hasura is not an 'either or' solution like Graphcool or Parse or AppSync. Hasura is designed to scale with the complex requirements of a project over time and to get out of the developer's way when they need more power. One of the main reasons why this is possible with Hasura and not possible with say Graphcool is the abstraction which Hasura provides. Hasura is not a black box which lets you do CRUD operations. It is a tool that adds powerful GraphQL APIs on top of Postgres, i.e, it works with any Postgres database, existing or new, no restrictions whatsoever. This means you are free to write your own code (and encouraged to) which speaks to Postgres directly with your favorite ORM and expose these APIs with "schema stitching" alongside Hasura. Hasura therefore lessens the work of a GraphQL backend developer: use Hasura's GraphQL APIs when they fit your bill and write your own custom logic when needed as you would have done without Hasura. In fact Hasura is a superset of Prisma when it comes to Postgres, you can also use Hasura as an ORM if you want to. Disclosure: I work at Hasura on graphql-engine

zackify 8y ago

With dataloading, you can turn anything that would need to be a join into two queries, using whereIns. It just takes a little extra work. I wrote a blog post on this exact issue a while back. https://zach.codes/graphql-query-batching-solutions/ https://zach.codes/graphql-query-batching-solutions/

zbentley 8y ago
> With dataloading, you can turn anything that would need to be a join into two queries *two queries and a lot of extra memory consumption.
jonnydubowsky 8y ago
Great post! Very helpful thanks

ThePhysicist 8y ago

I think Hasura takes care of building „good“ SQL queries that retrieve the data in a single request. I agree that it’s often not viable to resort to the standard GraphQL resolvers that will produce n database queries when asking for a list of items with a corresponding joined field. A while ago I built a MongoDB->SQL wrapper that would take a MongoDB query (with arbitrary many nested $include entries) and convert it to a single SQL query, which worked quite well. Of course this didn’t have any logic to check for permissions as we weren’t “crazy” enough to let arbitrary clients formulate the queries (we did it in the backend). The code is available at https://github.com/adewes/blitzdb https://github.com/adewes/blitzdb, we used it with https://github.com/QuantifiedCode/QuantifiedCode https://github.com/QuantifiedCode/QuantifiedCode.

tirumaraiselvan 8y ago
You are right. Instead of writing resolvers for each graphql node, Hasura compiles the graphql query into a single SQL query. Read more here: https://blog.hasura.io/architecture-of-a-high-performance-graphql-to-sql-server-58d9944b8a87 https://blog.hasura.io/architecture-of-a-high-performance-gr... PS: I work for Hasura.

nikolasburk 8y ago

Disclaimer upfront: I work at Prisma.io :) It's very important to properly distinguish Hasura and Prisma (as well as AppSync & Graphcool while we're at it). Hasura, AppSync and Graphcool are all Backends-as-a-Service (basically "Firebase for GraphQL"). You get an instant GraphQL CRUD API with a database and some ways to configure authentication/authorization. This is great for simpler applications but typically comes with limitations when requirements become more complex. Speaking from experience after 2 years of running Graphcool, we've learned from our customers that (especially larger) development teams quickly outgrow the capabilities of a BaaS and need more control and flexibility in their technology stack. This was exactly the reasoning why we've moved to Prisma which now replaces traditional ORMs and makes it easier for developers to build GraphQL servers (but also other applications like REST APIs). Another point is that GraphQL was invented as a query language for APIs, not databases. Exposing a CRUD GraphQL API to client applications was never the purpose of GraphQL - clients should still be able to consume a domain-specific API that's tailored to their needs (you typically don't want to expose all CRUD operations to your clients in a production application). With Prisma, we're trying to create the right abstraction™️ that helps people get started quickly but at the same time Prisma should remain the proper tool for them as their projects scale and grow in complexity.

vsurabhi 8y ago
While Hasura is a 'BaaS' (in the sense that it can be directly exposed to frontend applications), it absolutely does not come with the limitations that you have mentioned. Hasura is not an 'either or' solution like Graphcool or Parse or AppSync. Hasura is designed to scale with the complex requirements of a project over time and to get out of the developer's way when they need more power. One of the main reasons why this is possible with Hasura and not possible with say Graphcool is the abstraction which Hasura provides. Hasura is not a black box which lets you do CRUD operations. It is a tool that adds powerful GraphQL APIs on top of Postgres, i.e, it works with any Postgres database, existing or new, no restrictions whatsoever. This means you are free to write your own code (and encouraged to) which speaks to Postgres directly with your favorite ORM and expose these APIs with "schema stitching" alongside Hasura. Hasura therefore lessens the work of a GraphQL backend developer: use Hasura's GraphQL APIs when they fit your bill and write your own custom logic when needed as you would have done without Hasura. In fact Hasura is a superset of Prisma when it comes to Postgres, you can also use Hasura as an ORM if you want to. Disclosure: I work at Hasura on graphql-engine