Provide extensibility to the query compilation process

[dima-guzman]

There are many real-life cases when the extensibility level to write @cypher()-based field expressions is not enough. Ex.: we have the concept of tenants implemented in our system with adding tenantId / tenantIds fields to our nodes. And we need the whole hierarchy of selection sets to be filtered out by tenantId or we might want to provide some custom authorization-related Cyper-based filters.

I would propose to make the query compilation process to be implemented with somethinng like Visitor-based implementation, so I can delegate all the compilation to the default Visitor and to get involved to the process of Cyper code generation at the certain level of document AST. Like a method visitFilers that allows me to add custom filters to add AND $cypherParams.tenantId in this.tenantIds to the final Cyper code forWHERE clause.

Actually as Apollo Pathetic translate.js with ugly 25-parameter functions does no allow to do something like that we rewrite query documents to add these filers and also we are diff-patching that translate.js to be able to filter on array fields facepalm.

I would like an approach of Visitors implemented over the whole GraphQl language compiler like here https://github.com/imkleats/neo4j-graphql-deepauth/blob/master/src/rules/AuthorizationFilterRule.ts

[fnfbraga]

+1! Implementing a visitor pattern here is a very good approach to support extensibility.

[darrellwarde]

I've applied an auth-2.0 label to this - this might seem odd, but it feels like extracting the where functionality out of the @auth directive might be a nice way of achieving the goals here, without going all the way to extensibility of the query compilation process.

[darrellwarde]

As above, filter rules of the @authorization directive can be used as a workaround to inject additional filters into a query, but we're never going to implement extensibility into our translation layer.