[Doc] JSON DQL mutation for GraphQL Schema requires clarification

[jdgamble555 (Jonathan Gamble)]

@Poolshark

I’m not saying that they break GraphQL specs but @auth contains quite a bit of business logic which should be handled by the server and not be applied to the schema directly. However, I’ve also said that I do not mind this approach as long as it does not go crazy.

I think you’re misunderstanding how @auth directive works in Dgraph. Keep in mind I can’t speak for how it is implemented under-the-hood in other databases.

The @auth directive is actually handled on the server. It is not middleware, as a long time ago, the Dgraph team, for better or worse, decided to put the core code right next to the core dql code. I can confirm this, as I have dug deep into the core graphql code.

The @auth does not get triggered, and then your final query gets triggered separately. In fact, it compiles with your query, as an extra filter. This means it is faster, and you ultimately just have one filter. If I look for todos, my @auth is going to filter for todos I have access to form the beginning, hence never over-fetching, and then filtering those results.

It is actually pretty powerful and remarkable. There are definitely issues with implementing complex @auth directives in large schemas, there are some missing features etc, but it ultimately doesn’t slow down your code any more than necessary.

FWI: This is exactly how postgres policies work and compile.

@Poolshark

I did not say that every user prioritises GraphQL but I’m almost certain that most users start using Dgraph because there is a schema only approach. Moreover, as this resembles basically Dgraph’s USP. The very first headline on digraph.io literally claims

I used to think this way, until I realized how big the Graph Database community is. A lot of people want something different than neo4j, and they don’t care about GraphQL. Dgraph is ultimately both a Firebase (Hasura) competitor and a neo4j competitor, and there sometimes isn’t a lot of overlap. I also suspect the Graph Database users (analytics etc) are the ones giving Dgraph the most money. There are also people in between who like and use both of course. Either way, I can tell you from many conversations on here, Dgraph isn’t quite sure the percentages, but they are certain who gives them money. This could have changed, however, in the last two years, but I doubt it. I could be wrong, but this is what I have gathered from the old active community.

@Poolshark

I do not agree. It has nothing to do with holes in the GraphQL layer. I would even advocate NOT to extend the complexity of the current GraphQL since you would put more and more business logic in the schema. At one point you might find yourself having an @execute directive, where you run command blocks - again, I don’t think that this should be part of the GraphQL schema. I already have such complex @auth rules which I would love to tackle properly with a programming language rather than query logic.

Most of the features I believe Dgraph needs, won’t add any more logic to the Schema itself. @custom dql queries are the equivalent to @execute btw.

There have been many posts about separating the @auth rules into another file. I think this would be a good idea. First thing is first and get a new version up and running knocking out some of these huge bugs (as well as things like pre-hooks).

J