[Doc] JSON DQL mutation for GraphQL Schema requires clarification

[jdgamble555 (Jonathan Gamble)]

@Poolshark

Dgraph runs these @auth queries before the actual request. That’s basically the definition of a middleware.

Yes, it is middleware, just not separate logic. Semantics.

@Poolshark

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.

Extremely strong statement to say useless. Lots of databases don’t give you the UID beforehand, it just depends on your setup. Without getting into it on this posts, this particular issue may be solvable by using @id instead, create a new post if you have questions about that.

That being said, I personally won’t use it as a full security level for mutations until some of the bugs and @auth feature requests are fulfilled.

@Poolshark

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).

Again, very strong opinion. GraphQL is meant to be consumed on the frontend just like Rest API (although not limited to frontend). There is a reason you pass Authorization headers. The spec just doesn’t care how you handle them (Constraints, Authentication, Authorization, use RBAC, GBAC…etc)

@Poolshark

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 you use GraphQL. You can use Dgraph without GraphQL. Just use the DQL schema directly and ignore the GraphQL schema. I suspect more than half its users don’t use GraphQL.

@Poolshark

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 have taken part in many internal and external discussions. The new Dgraph team is focusing on both: the GraphQL Layer and DQL Layer as a Graph Database. Ultimately the foundation needs to be good at the bottom layer-up regardless.

This is again another strong statement from you, as completely separating logic would slow down your app. Perhaps we can agree that from a DX perspective, it should be separate, but should ultimately compile down to give use the fastest queries possible without over-fetching.

@Poolshark

That’s what we do already because otherwise @auth rules are not maintainable in a larger projects

Well everyone definitely agrees with this that has built a medium sized or larger project.

The GraphQL spec is simply not opinionated on how you handle business logic; I personally wish it were. The @auth directive is just one pattern, and definitely has its problems. It is also not meant to handle constraints either.

I believe the Dgraph team is aware of these sufficiencies, and will eventually find a better way to separate this logic from a DX perspective. There is just so much work to be done first. I personally like the way Hasura does it.

J