Thanks @aman-bansal. I am looking forward to it!
One of the great uses of this thing for me will be field validation as I spoke of above. It will solve so many problems you guys don’t even realize.
It seems neo4j uses something called bind for their after-update validation. Every other graphql implementation I found pretty much has internal mechanisms for these checks outside of graphql.
You guys have to remember that Dgraph does not have any internal contraint testing like Cypher and SQL can do.
Please do not let this be the last GraphQL feature you guys program for a while.
While this is the biggest one (arguably tied with nested filters), there are a few core graphql features that you will have to have. I am not talking about needs for some, but needs for MOST.
For Your Reading Pleasure and Reference…
You have already started coding…
- Error Codes / Messages in GraphQL
2021 Roadmap - not sure I know what is up-to-date on here and what is not
Which are these SQL Equivalents
- Many-to-Many Joins
- NOW() Timestamps
- Foreign Key - DELETE CASCADE / UPDATE CASCADE
- SQL Triggers - Before AND After
- SQL Composite Key
- SQL Contraints - CHECK, NOT NULL, UNIQUE, DEFAULT
- SELECT DISTINCT
You can see a pattern of what was forgetten in GraphQL, because other Databases handle these problems internally, unlike Dgraph.
Other GraphQL Implementions to Get Ideas From
Plenty more like Contentful, but these 3 are the most widely used…
I think that is it. These are regular features in other databases that solve MANY problems, not just for a few.
@mrjn - If you truly want to compete with PostgreSQL This is how you do it.
@amaster507 - Let me know if I forgot something.
@aman-bansal - Please read through these so you understand what is truly missing in Dgraph GraphQL
I am not trying to make a general feature list, but GraphQL is also the Middleware for everything in Dgraph, this list is everything, and can be done in 6 months and be done with it.
That’s all she wrote.