Yup. That's something we can handle internally, under the hood to batch database requests into a single query for all edges. This problem is actually easier to solve in GraphQL then it is with a traditional REST API.
Exactly, now you put the onus to solve N+1 on the serverside, instead of in the old case the client would do N+1 requests...
you can use a helper library like the wonderful graphql-sequelize [https://github.com/mickhansen/graphql-sequelize] which helps you get from an ORM like sequelize to graphql queries/results fairly easily.
You can use something like dataloader[0] or haxl[1] to help with this issue.
Re:The GitHub GraphQL API
by xentronium on Thursday September 15, 2016 @04:06AM
(#12504257)
In rails/graphql combo it's resolved the same way you usually resolve n+1 queries: you make 1 request per type of edge (i.e. one request for posts, one request for authors, on request for comments)
Does anyone know any best practices if you want to adopt this is in an existing application using a relation database (i.e. PostgreSQL). I don't know how to implement this without causing N+1 queries. (or Worse).
For example:
{ Post {
.. } } }A naive implementation would cause a lot of query, for each "edge" a query.