Love how this turns into a proper discussion here! 
Although I havenât dug deep into the the source code of Dgraph, I am pretty confident in my understanding of @auth. Of course @auth is handled on the server, there is no other way since GraphQL is nothing else than a query language. Therefore, your comment that there is no middleware is not really accurate - Iâd say that you donât have access to the middleware directly but, as you have stated yourself, Dgraph runs these @auth queries before the actual request. Thatâs basically the definition of a middleware.
Again, I have no problem with @auth but it is certainly an extension of business logic which GraphQL (as a query language) is simply not made for. Furthermore, in my opinion @auth for add mutations is completely useless since you do not have access to a valid UID yet. The only thing you can test for is key-value pairs in the user claim. But again - Iâm not against @auth, Iâm only saying that abusing a query language by implementing business logic might become. a dangerous path. Especially considering that the GraphQL team most certainly will not work towards something like that.
So just to clarify: Since GraphQL is a query language it should not be responsible for business logic other than the representation of it in the schema itself (my opinion). It is a great tool for filtering and thatâs certainly something very powerful in this context. However, at least in my use-cases, it causes more problems (eg. no field protection and thus compromising the GraĂźhQL schema, etc.) than having an additional âmiddlewareâ which lets me do auth properly.
As of performance, I donât see a reason why a separate auth middleware (or an auth middleware where you have access to) should slow down the process. I think it only depends on how you implement things and how you write your code. Iâm not sure but I could imagine that if someone goes crazy with queries inside @auth you could also slow down the process.
It certainly is! But that has nothing to do with Dgraph as a company. Dgraphâs approach is schema first - you yourself stated that âyou should never touch the DQL schemaâ. So if this is the case, then even if people are interested in the graph database only, they still need to deal with somehow with Dgraphâs âGraphQLâ part. If Dgraph should decide to focus more on the powerful graph DB, then even more so, logic needs to be separated from the actual query language. I 100% agree that there probably are quite a few people who want to build their own API around Dgraphâs graph DB - eg. @amaster507 client.
Thatâs what we do already because otherwise @auth rules are not maintainable in a larger projects - at least not in ours but that of course could also mean that your schema design has flaws. However, just separating into another file to have some of the stuff available for re-use, does not mean âit is not part of the schema file anymoreâ. You just made it a bit better looking.
Anyway, thanks for the discussion! 
Iâm thrilled to see what Dgraph will bring for us in the future!