Design Concepts looks like someone ripped off the first 10 pages of it.
I am playing with the Dgraph for a while and I like the idea. I am sure that you are aware of the problems and be sure that we, the community, have the patience.
But, please, try to solve the basic issues. From the place where I am concerning Dgrap usage, those are the two issues that I see as the most urgent.
Timestamp controlled by the database (or default predicate value, e.g. time.Now()). Backend, or in Dgraph case GraphQL API, is the source of truth for when the object is created. If there is a workaround for this, please put it into the doc.
Auth on predicates for GraphQL API is very important for example âstatusâ field is very common and almost all the nodes should have it. The solution should not be some kind of walkaround since it has to be efficient. If there is a solution how to solve this on the level of the schema, please put it into the doc. (I do not see the reason why interface auth is inherited to the whole object that implements it, since that would solve the issue).
So timestamps are available in v21.12, it is just not on the cloud yet. However, even when they are available, you cannot secure them correctly until #2 is implemented. I have created a work-around you can do in v21.03 or greater.
I 1000% agree. I have been preaching this for the last year. Keep in mind this feature is very closely-related to the update-after @auth directive, depending on how dgraph decides to implement it.
You are completely right that the only secure usage of GraphQL API is with all @custom mutations. Lambda should not be the patch for GrpahQL API security issues, but a helper for the implementation of the more complex operations upon the database. That approach is not responsible and professional.
If the Dgraph team is aware of those basic (!!!) security issues they should put it in the documentation as a temp solution until the proper GraphQL API solutions are there. Otherwise, Dgraph becomes a time-consuming product more than writing our own old fashion backend. Without that in the documentation, their TODO example stays on the level of the âHello Worldâ example.
From the topic you created, I see that you have some suggestions. I am a Go developer and I hope to find a time to look into it more deeply, but from some of the answers you have got from the Dgraph team I first have to find a motiv. I just cannot understand that someone has to be even persuaded into this. The only proper answer to this from the team should be âYeah, yeah, we are on itâ.
Welcome to my world. I am hoping we are going to hear from Manish at the beginning of the year about the future of DGraph, including a roadmap. I suspect he knows this needs to be on it at the top of the list by this point.
Please stick around, I believe you could help us out. I think some of us even thought about going through the code and learning Go.
