Teach graphql integration to preload filters

[stephenh]

If a GraphQL query has super-obvious filters like:

query { books(filter: { title: "..." }) }

We could auto-map those to SQL WHERE clauses. The wrinkle is that usually there is a long-tail of filters that want to be "short-cuts" for the API, i.e. something like isPublisher=true maps to status => publisher or publisherId=2 maps to book.author.publisher.id=2.

We could potentially teach any entity to have a list of "out-of-the-box filters", which are basically rails scopes, like a map to:

• Book.scopes
  • publisherId => ...expression that we can eval...
  • isPublisher => ...expression that we can eval...

Some of these scopes we should be able to create implicitly, i.e. from:

• Primitives on the entity
• Codegen-d relations on the entity
• hasManyThrough / hasOneThroughs on the entity
• Custom scopes (?) from like config.addScope? Would need to take an argument (the filter value(s)) and return a ParsedFindQuery-ish AST of how to execute it

It seems like filters would largely group into two buckets: within-entity & cross-entity. Within-entity filters can be evaluated using only the columns within the current table. Cross-entity filters need to do joins. This would have implications for relations maintaining the consistent worldview, b/c if a new entity is added to a filtered-down relation, we'd need to runtime eval the filter against the new entity.

Like if a GraphQL query was author(id:1) { books(filter: { status: published }) { title }, and we preload only ~10 of the authors 100 books, the a1.books collection is not actually fully loaded. And adding a new book may-or-may-not match the status = published filter.

I wonder if these filters are almost dynamic relations, i.e. should be seen as author -> books -> books(filter) that have their own dynamically-created relation, with its own loaded state. We have had difficulty doing things like author.books.load(...) --> ... in the past with the type system, so that doesn't bode well.