neo4j-graphql-js
neo4j-graphql-js copied to clipboard
neo4j-graphql
Feature Request: Custom path pattern WHERE Clauses
One powerful feature of neo4j is the ability to use path patterns in WHERE clauses. I think implementing a custom @where directive that allows for the inclusion of such statements into the generated Cypher could have some great mileage (not to mention the potential to help overcome some of the frustrating features of GraphQL).
I'm not well-versed on directives yet to think I'd be much use, but I was thinking through how to alter the neo4jgraphql function and use a custom resolver to accomplish the same thing. Happy to help as much as I am able.
That's a great suggestion. I'm thinking this would be a good fit for when we add support for a filter argument.
@johnymontana This idea was the generalization of a specific use-case in which I was interested: implementing fine-grained access control. After reading up on the GraphQL documentation, it seems there's a philosophy that Authorization/Access should be implemented through the Business Logic layer (despite many available examples of incorporating simple access control through type/field directives).
That being the case, I've created a fork (https://github.com/imkleats/neo4j-graphql-js) that implements some access control features by allowing generator functions to be passed through the context object to create the necessary Cypher statements. The bones are pretty much done (maybe?), but even though the changes don't break existing tests, it could use its own unit tests.
Hey @imkleats this is really interesting.
So the ACL function is specific to a Query/Mutation field, and not to the type? Am I understanding the idea correctly? I'm just trying to think how this would work in the case of generated queries and mutations. Maybe seeing an end-to-end example would help me wrap my brain around this. Is there an example in your fork you could point me to?
Your first question could be referring to a few things, so I'll try to hit them all. As it stands right now, the ACL function is specific to the CRUD operation a Query/Mutation is performing. The functions itself should return an object with parameters that can then be threaded into the first level of the query generated by translateQuery/translateMutation (i.e. I haven't gone into the subqueries yet). In this sense, it is applied to the root Type of the associated Query/Mutation, which the option to blacklist/whitelist specific Types.
I will put in an example of what I am envisioning the auto-generated query to be as a guide post. I just haven't had the time to debug what I've currently tinkered with in the codebase (aside from making sure it didn't break current tests) and honestly thought others might have better implementation ideas if I just got the core idea out there.
Despite these custom predicates being inserted on the main entry point to the query, I think the ability for a developer to access the resolveInfo themselves opens the door that they could use those predicates to call one or more stored procedures on the database itself to utilize some of the native field-level access control that Neo4J has been incorporating.
(Edit: This all has the potential for extreme customization of auto-generated queries, applications of which far exceed mere access control. For this reason, I was considering refactoring a little to allow for those folks who might not be familiar enough with the inner workings to define some "simple" plain text predicates outside of a full-blown generator function.)
@imkleats WOW thats exactly what we need currently, the ability to alter the generated cypher query. Thats not just intressting for ACL but also other usecases where more flexibility is needed! @johnymontana this would be awesome if we could have such (or simililar) ability!!!
