I believe you are noticing what I noticed is the number one problem with Dgraph… a reasonable, scalable approach to backend security (this includes what is going on in the schema).
Here is one post I am eager to see the DGraph team expand upon:
While I disagree with you on one thing, I think your end result is in agreement with mine.
- The schema needs to be separate from @auth @custom @lambdas - this makes it incredibly difficult to maintain any large projects that scale… there is too much going on (and it doesn’t even pretty print)
- Input Validations are a must (see the link above) - a simple fix for now would be a pre-hook which would allow whatever you want… I also love the idea of something like firestore rules in the future, as it does basic boolean checks without slowing down the query, and is very very powerful
- Field Validation Rules - along with field validation comes a way to BLOCK certain fields from being added, changed, etc depending on certain conditions (without creating a new mutation or type)… this is really a caveat to the later
Which leads me to why I completely disagree with you on spearating the DQL and Graphql (as far as the way graphql is now)… It will be ERROR PRONE. Why mess with that on a lower level like in your example when you could achieve the same desired result on the upper level (in this theoretical future would of dgraph). The same result could be achieved by locking anyone (except admins if that is what your rules say) from posting to createdAt, for example, and adding that functionality in a pre-hook with a server timesteamp. If you’re an admin, you could, however, change it. A simple validation that locks that field would solve your problem.
I don’t see any reason to modify the way GraphQL connects to DQL to accomplish your needs. I also agree with you that other languages should be added to things like lambdas, post-hooks, and pre-hooks (python, php, probably not perl, RIP). However, this would only be available when you don’t use Cloud Dgraph, and when the Dgraph team has time to write packages for them (a working slash-dgraph-cli is a must first, for example!)…
Simpler is better. I, like yourself, love Dgraph. I forsee this as the number one problem with Dgraph.
A lot of other issues are already in the works, but I believe they have not decided how to handle this problem quite yet… do a quick search on the form and you will see many related posts.
J