5 ms·

I think the idea underlying this post is this: Sometimes you are creating an application and building its underlying datastore at the same time. Hasura is grea

I think the idea underlying this post is this: Sometimes you are creating an application and building its underlying datastore at the same time. Hasura is great for this. But sometimes you already have a disparate ecosystem of services and datastores and you want to provide a GraphQL API for that. This use case is better-served by other approaches.

lowwave 6y ago
And sometimes with nested GraphQL queries it just grind the db to a halt. It may be a good idea to convert it to SQL and optimized it by hand. Great tool. Personally I don't trust GraphQL completely.
- praveenweb 6y ago
  In a production app, you would limit the query depth or have an allow-list to prevent arbitrarily nested queries.
  - andrewingram 6y ago
    Back in 2017 when I was doing a lot of work on optimising GraphQL, I briefly looked into how likely it was that a UI would actually end up requiring a query with problematic performance characteristics. The answer seemed to be “not very”. I had to come up with a deliberately contrived UI to find a realistic query that was more than 4 relationships deep. Most were around 3 (though double-nested connections were fairly common within this). The more common problem was around overall data size, where the bottleneck was JSON serialisation overhead and network transfer size. Query whitelisting is the winning approach for 1st party APIs. If you’re opening things up to third parties, e.g. the Github API, complexity analysis becomes the more valuable solution.
tango12 6y ago
On a related note, Hasura has Remote Joins which allow bringing different data stores, setting up "join conditions" and then being able to make queries that fetch data across those sources. Hasura then plans an execution which does a "push down" to the right source. For example, the database bits in so far as possible are compiled into a single SQL query and pushed down to Postgres. API calls are batched. You can join across Postgres, GraphQL and REST APIs. Scheduled for the 1.3 release this coming week!
- chrisweekly 6y ago
  Cool!
xuorig_ 6y ago
Author here, thanks, that's exactly it ^

lowwave 6y ago

And sometimes with nested GraphQL queries it just grind the db to a halt. It may be a good idea to convert it to SQL and optimized it by hand. Great tool. Personally I don't trust GraphQL completely.

praveenweb 6y ago
In a production app, you would limit the query depth or have an allow-list to prevent arbitrarily nested queries.
- andrewingram 6y ago
  Back in 2017 when I was doing a lot of work on optimising GraphQL, I briefly looked into how likely it was that a UI would actually end up requiring a query with problematic performance characteristics. The answer seemed to be “not very”. I had to come up with a deliberately contrived UI to find a realistic query that was more than 4 relationships deep. Most were around 3 (though double-nested connections were fairly common within this). The more common problem was around overall data size, where the bottleneck was JSON serialisation overhead and network transfer size. Query whitelisting is the winning approach for 1st party APIs. If you’re opening things up to third parties, e.g. the Github API, complexity analysis becomes the more valuable solution.

tango12 6y ago

On a related note, Hasura has Remote Joins which allow bringing different data stores, setting up "join conditions" and then being able to make queries that fetch data across those sources. Hasura then plans an execution which does a "push down" to the right source. For example, the database bits in so far as possible are compiled into a single SQL query and pushed down to Postgres. API calls are batched. You can join across Postgres, GraphQL and REST APIs. Scheduled for the 1.3 release this coming week!

chrisweekly 6y ago
Cool!

xuorig_ 6y ago

Author here, thanks, that's exactly it ^