How to look-ahead when resolving an entity?

[edmondop]

I had this setup:

type MyStuff {
   .. other stuff ommitted
  entries: [Entry!]!
}
type Query {
  myStuffs(
    stuffFilter: StuffFilter
    entriesFilter: EntriesFilter
  ): [MyStuff!]!

my resolver invokes a single service, passing down the entries filter.

I am considering a more graphql-idiomatic approach like so:

type MyStuff {
   .. other stuff ommitted
  entries(filter: EntriesFilter): [Entry!]!
}
type Query {
  myStuffs(
    stuffFilter: StuffFilter
  ): [MyStuff!]!

however in my resolver now it's unclear how to extract the filter from the query to pass it down to the service level. How do I do that?

[PatrykWalach]

You want to use info to parse the AST. Here's a great blog post about info field in javascript .

You want to start with info.field_nodes to traverse through fields myStuffs -> entries to get arguments AST. Then parse the AST into object, you can find variables to substitute in info.variable_values.

[PatrykWalach]

Looking ahead is not easy, you have to handle:

• fragments
• what if entries if not selected at all
• what if entries is selected more than once, for example:

fragment _ on MyStuff {
  entries(filer: true)
  moreEntries: entries(filter: false)
}

[edmondop]

I am wondering whether it is not a "real problem" that is not easy. It's "my fault" that I am developing granular resolvers for fields, because I have everything in a relational database. If I didn't resolve the parent entry and the children with a single join, but two SQL queries, this would be easy to handle.

There is an opposite argument instead that a good GraphQL framework should make multiple data resolution strategies in the backend equally simple to implement correctly, I don't know

[PatrykWalach]

Most GraphQL frameworks have a limited scope of defining schema/resolvers, they don't provide an answer on what to do inside of resolvers.
I saw at GraphQL Conference a talk about Grafast, it allows for building a single database query, or use of minimal amount of queries. You might be able to find a python alternative.