Re:How and why GraphQL will influence the Sourcehut alpha
by snorremd on Thursday June 11, 2020 @05:19AM
(#23486778)
Hasura is one example of a graphql server that uses the SQL joins pattern to optimize graphql queries. See https://hasura.io/blog/architecture-of-a-high-performance-gr.... It automatically generates graphql queries based on your own schema and translates it to efficient postgres sql queries. The post I linked also briefly discuss the Dataloader pattern for batching graphql resolvers to avoid the N + 1 problem.
Re:How and why GraphQL will influence the Sourcehut alpha
by zwkrt on Thursday June 11, 2020 @01:33PM
(#23491202)
For a fun hack-week project I created a graphql server that would automatically create any necessary SQL tables to support a query given to it. So if you made the query
query {
user {
name
email {
primary
secondary
}
posts {
body
karma
}
}
}
I wouldn’t expect the performance issues to be much more problematic than they would be for REST endpoints that offer similar functionality. If you’re offering a public API, then either way you’re going to need to solve for clients who are requesting too many expensive resources. If you control the client and the server, then you probably don’t need to worry about it beyond the testing of your client code you would need to do anyway.
As far as query optimization goes, that’s largely out of scope of GraphQL itself, although many server implementations offer interesting ways to fulfill GraphQL queries. Dataloader is neat, and beyond that, I believe you can do any inspection of the query request you want, so you could for example see the nested path “Publisher -> Book -> Author -> name” and decide to join all three of those tables together. I’m not aware of any tools that provide this optimization automatically, but it’s not difficult to imagine it existing for some ORMs like those in Django or Rails.