Reducing executor

Hello!

In our system we took GraphQL query and translated it to ReQL (RethinkDB query language) for execution. This allowed us to optimize the query, eg use built-in joins in ReQL instead of querying the database two times. I can see how the similar system can be used for, eg, SQL queries. We also did some further optimizations, like returning only the fields that are requested by GraphQL, reducing the response payload size for tables with many keys.

I see a way to do it graphql-js by manually going through selection sets in resolve, but that feels very clumsy and hacky, as the library does this walking already. Some ways to do it would be to allow children resolve to modify root or to split collect/resolve/complete steps into independent parts that can be used separately.

Do you think deferred execution and query translation is a good idea? Should we stick to current model and do multiple requests to the database? Is there some solution to that, which I don’t see?

Thanks!

[syrusakbary]

I like the idea of reducing executor. I’m running in a similar problem when trying to optimize the queries to the DB when querying through GraphQL.

I got a way to make it work with graphene but it feels hacky

[ruslantalpa]

@helfer you are right about passing data down (looking into it). Using that one could create “smarter” resolvers that can prefetch data for their children (and with that eliminate the need to reduce the number of resolvers). I don’t think the coupling is a problem since its a thing dictated by the problem being modeled (client project relation is not going to change)

@JeffRMoore reducing the number of resolvers would have the same effect, but you are right, strictly speaking the goal is to reduce the number of backend trips.

@taion don’t want to start a flame war about the ORMs 😃 but just because they are doing it that way does not mean they are doing it the right way. If you look more closely at my query you’ll see there is no “cartesian explosion”, the shape of the response is EXACTLY the shape GQL will return. The fact that it uses functions like array_to_json has nothing to do with the executor or generality this implementation needs to maintain, that is handled by my resolvers anyway so i am taking advantage of the features the backed (PostgreSQL) offers me. The reason the ORMs are doing it that (suboptimal) way is because they target all the databases so they use only features available in all of them (standard sql) but since i am using only one backend (actually everybody does when using an ORM) then i am going to take advantage of the features it offers (and throw away broken abstraction)

In conclusion, first of all i would like to apologies for derailing the discussion a bit. While in context of “sql backend” what @helfer suggested, solves the problem of optimising the backend trips, there might be situations where this is useful. What are your thoughts of providing a way for “reducing” the number of resolvers (that generate backend requests) by allowing resolvers to exist independent of “type definitions” and attached to the AST nodes. This would give a way for an outside function to control to some extent the “execution” phase