We were wondering how we could implement attribute-based access control https://arxiv.org/pdf/1909.09904.pdf together with Dgraph’s GraphQL API. If we did write our own resolvers, we may not be able to use Dgraph’s generated GraphQL API. What might you guys suggest?
Could Dgraph GraphQL work with Apollo’s Federation as well?
I suppose this Dgraph forum post actually answers this question. I was planning to use Federation to enforce access control but that wouldn’t work because queries could always snake their way via predicates into Types they aren’t privy to see. Now that each Type will be filtered by @auth(), that problem is resolved. No snaking allowed.
Unfortunately I still have a problem… because in my job, access control might be dynamic and complex, e.g. needing to call an external service to check if today is a working day… and even though Dgraph starts to remind me of writing stored procedures, I don’t think she’s capable of calling http requests as of today. Although I partially wouldn’t mind GraphQL turning into a turing complete, OS API calling, programming language.
Ultimately though I might roll the traditional Apollo Server (Node.js) way to manage access control, and just call Dgraph’s GraphQL in my resolvers; although there will be a lot of dataloading and not to mention coding of barrelling of params for pagination and sorting etc. Can’t think of anything better right now. 
Hi, thanks for the question. Yes we are adding the kinds of access control that you are talking about. We are also adding this GraphQL Custom Logic that does allow you to call external http to resolve fields.
So you will be able to mix custom logic and auth together. I wonder if that mixture will be enough for your needs? It would be great to talk to you more about your use case and see if we are working towards will work for you. Or if maybe we’d need something like @custom auth so as well as custom field resolvers, you could provide some sort of custom auth handler?