code generation support for filters

[willscott]

The current schema generation does not provide support for parsing incoming arguments or offering filtered views of lists based on matching fields within the dag of the items in the list.
This should be doable in a general way as part of codegen.

[willscott]

generic filters on immediate struct fields/map keys is demonstrated in https://github.com/graphql-go/graphql/blob/master/examples/httpdynamic/main.go#L75-L84
and can be built up without too much trouble.

The part that becomes scary is if you allow filters on the full subdag you've realized for each type, because while possible it probably makes the schema/reflection/generation jump an order of time-complexity, since you're re-parsing the sub-dag schema at each point.
While scary in terms of the implications both for data loading performance and schema interpretation performance, deeper filters are also a functionality that's going to be wanted for a lot of queries "give me the items of this list who have property x set to y".

[warpfork]

Are you sure you're not describing features you might want from Selectors, rather than from the Schema codegen?

There's a whole zone of the Selectors spec that's reserved for a "Conditional" system, which is able to peek down the tree. (Or is proposed to have that feature, anyway -- the current state of it is an outline, and there's no implementation that I'm aware of.)

[willscott]

in the context of a graphql query, there is a defined type system called an 'input type' where you can provide the graphql client with the schema of how they're allowed to filter their queries against the dag.

So for instance

query {
  Movie(
    filter: {
      actor: { name: "Brad" }
    }
  ) {
    title
  }
}

is an example graphql query with a 'nested filter'.