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. 