4/9 of the items on that list have been resolved and 2 won’t/can’t fix.
Yes and no. @custom now works with @auth to some degree: WIP: Auth rules custom DQL query, I believe paging (at least param passing) works. But maybe not the complete control that a user wants. SO then the other option is to put the DQL in a lambda (mixed emotions) and then do your custom logic, filtering, auth, in that lambda script.
Filtering has limitations, yes, but every API will have their own set of limitations on filtering to some degree. For a known unique filter need, a custom query or lambda script may still be a viable option and suffice the need without needing to create an entirely backend layer on top of Dgraph.
With all of this being true, and if this find mutual friends was a common query need, I wouldn’t mind making a custom query for it. Given my example above, if there were any auth rules on the Person type, they would trickle down to a custom query that returned nodes of that type which would suit most of the need most likely.
Would a option to filter child nodes be a better fix for this situation if RFC: Nested Filters in GraphQL was inmplemented sometime down the road? Most likely (if it was done correctly) But that query would probably look like:
query {
queryPerson(filter: {
and: [
{ friends: { id: ['0x1'] } }
{ friends: { id: ['0x2'] } }
]
) {
id
name
}
}
to check for having BOTH instead of just having EITHER