GraphQL Query Planner

[rmosolgo]

I'm really interested in leveraging GraphQL's "compile-bility" a bit more. For example, it should be possible to inspect a GraphQL query and write the correct SQL queries (and/or external service calls) to fulfill that query.

The API of my dreams involves two parts:

1. Some way for users to specify how fields are fulfilled, and how those specifications may be combined
2. A first-class graphql-ruby API for surfacing its execution plan based on those specifications. (eg puts MySchema.plan(query_string, context: ctx))

I think the resulting system could be very powerful: you could make some predictions about database access before running the query and iterate on your configuration to make it correct and efficient.

However, it will also be very hard 😄

Also, it's important for me to make this incrementally adoptable. I think this will be manageable: the default plan for every field is "just call field.resolve", I think that's the starting point.

GraphQL::InternalRepresentation is a de facto query plan right now, but it has some issues:

• It depends on query variable values: Namely, @skip/@include are applied at that time. Nodes are removed from the tree if they are skipped, and query variable values are required to do that. To make the plan more portable, we should allow static planning (from a query string alone)
• No user-friendly APIs: it's build to make execution easy, not to make inspection easy. As a result, it's hard to answer simple questions like "is field X selected?".
• Implementation issues: its approach to fragment inlining is not good (this is because it converts the query into a deterministic finite automaton, I think a more efficient approach would be to use a NFA with runtime switches as part of the machine, this is how it used to work)

My goal will be to make it compatible with Schema-from-IDL as discussed in #727 and useable somehow via DSL.

What do you think, would this API be useful in your system? Are there other considerations we should make?

[bessey]

I think this is really intriguing, and have been thinking about it myself. With the current API its pretty trivial to avoid N+1s, but not so easy to avoid over-fetching within a single table. If there were some way to annotate a field with the column(s) it will access, and have the parent node's resolve take this into account, the penalty for accessing a couple of fields on a wide table could be totally eliminated.

[fameoflight]

@rmosolgo just wondering what happened to this? did you ever try to implement this?

[xpol]

There is Join Monster did this, but it is for JS.

[rmosolgo]

I looked at this some, but I think instead I will make a multi-pass interpreter instead, keep an eye on #1394