1) ACLs. Say we want to use an Acl object that looks like this:
type Acl {
readers: [Group]
writers: [Group]
owners: [Group]
}
Then on the server we want to filter items out that dont' match the Acl, e.g. requiring context.user.userID to be in the set of {all users in all groups of acl.readers}.
2) Search ranking, using signals that are nested in objects below the top-level item.
In both of these cases, we need to do filtering or sorting after the objects have been fully resolved. But it doesn't seem the Apollo server resolver framework gives us a hook for that. If you do it in the resolver for some level of the query hierarchy, then the child items won't be resolved yet; in the current demo they are just string ID references at that point.
What we want is a callback that runs on the way back up the resolver tree, not just on the way down.
Motivating use cases:
1) ACLs. Say we want to use an Acl object that looks like this:
Then on the server we want to filter items out that dont' match the Acl, e.g. requiring context.user.userID to be in the set of {all users in all groups of acl.readers}.
2) Search ranking, using signals that are nested in objects below the top-level item.
In both of these cases, we need to do filtering or sorting after the objects have been fully resolved. But it doesn't seem the Apollo server resolver framework gives us a hook for that. If you do it in the resolver for some level of the query hierarchy, then the child items won't be resolved yet; in the current demo they are just string ID references at that point.
What we want is a callback that runs on the way back up the resolver tree, not just on the way down.