Suggestion: Why not using OpenCRUD specification?

Users GraphQL
4

Connections
> WIP
https://www.opencrud.org/#sec-Connections

yep!

No, I mean what is the WIP part of the spec as referenced above and found in 2.4.2.2 with a really verbose and meaningless example found at 2.4.2.3

But does it really actually do this that you are claiming? Let’s put them side-by-side

| OpenCRUD       | Dgraph's GraphQL |
|----------------+------------------|
| user           | getUser          |
| users          | queryUser        |
| userConnection | aggregateUser    |

So what is the difference other than symantics?

It might be better to understand if the spec actually had an example on this and not just stating it was possible by the spec. 2.4.4 is incomplete spec IMHO. It is missing 2.4.4.1, 2.4.4.2, 2.4.4.3, 2.4.4.4 which is outlined but not documented, Which makes me wonder if instead of the 3 operations above if there are actually 4 operations and the 4th is just not exemplified in this poor excuse for a specification. userConnection would belong to some example missing in 2.4.2.2 and maybe there would also be a 4th query operation names usersAggregate that should be exemplified in the missing 2.4.4.4

This makes me wonder why the actually harder parts of the spec are missing maybe the spec is unfinished and not updated in the last 9 months because it was a failed project? Reminds me of the verbosity of trying to implement GraphQL with Relay. Dgraph is not Relay compliant in a broad sense, but does things better than Relay in a broader sense (globally unique uid).

On this topic, Relay is trying to fix the GraphQL implementations that are inefficient because they are layers on top of rdbms/non-graph no-sql dbs.

Relay handles the heavy lifting to ensure the data declared by your components is fetched in the most efficient way. For example, by deduplicating identical fields, and precomputing information used at runtime, among other optimizations.

Most all of these inefficiencies are handled natively by Dgraph without the need to really complicate the API and force the front-end to use fragments and add a nested node edge to every query.

The main parts missing right now in Dgraph’s GraphQL API compared to OpenCRUD are

  • “Cross-relation filters” (2.4.3.6) aka nested filters with WIP RFC: Nested Filters in GraphQL
  • “Mutations: Nested” (2.5.3) which is handled by Dgraph to add new but not update. There have been multiple conversations about this in this forum and this seems to be a controversial topic of what should and should not be allowed by an API. As Dgraph’s GraphQL API is all auto-generated it comes down to what the engineers decide on this matter.

Another aspect that seems somewhat complicated is OpenCRUD’s tree-modifiers that Dgraph handles with cascade and not/has filters.

And to counter your point with actual spec, again you stated:

Where Dgraph would generate the mutations

  • addUser
  • updateUser
  • deleteUser

OpenCRUD would generate the mutations

  • createUser
  • updateUser
  • deleteUser
  • updateManyUsers
  • deleteManyUsers

And it is not even clear if createManyUsers is spec compliant. So instead of 3 mutation operations for a single type we would have 5-6 operations. So what was your point again? lol.