Suggestion: Why not using OpenCRUD specification?

Users GraphQL
1

I find GraphQL API of dgraph more intuitive to use than DQL one, thanks to way better tooling (graphiql + extensions),
but GraphQL is missing a lot compared to DQL,
so why not implementing GitHub - opencrud/opencrud: OpenCRUD is a GraphQL CRUD API specification for databases and extend it for functionality like full text search, fuzzy and geo search?

thank you

2

@graphql, Please don’t. This spec is still a WIP and is overcomplicated to what we have already with Dgraph’s GraphQL API. Just look at how it handles field operators compared to how Dgraph does it. It is easier to build dynamic web applications by separating the field and operator into two separate pieces which improves API flexibility and schema reusability. And don’t even get me started with their weird syntax for connections… no thank you. Keep it simple please

3

Thanks for your opinion,
but let me kindly disagree on some points, and let’s hope our discussion will bring more attention and love from the dgraph team to graphql API :slight_smile:

  1. “This spec is still a WIP”
    How you came to that conclusion? Prisma v1 implemented it and was partially implemented by others (e.g. Postgraphile) for years

  2. “It is easier to build dynamic web applications by separating the field and operator”
    totally agree with you, the dgraph way is a lot easier to follow and build a dynamic input for a filter on a search results page with multiple filters (color, price range, other attributes)

  3. their weird syntax for connections
    if you mean the connection with cursors it is not really “theirs”, it is the official graphql recommended(?) for pagination and used by relay

In my opinion OpenCRUD does a better job of unifying everything under one model instead of having 3 different nodes/calls for query, get, and aggregate and
it proves that it is possible to describe with GraphQL all those complex queries that are now available only in DQL, e.g. groupby with aggregations

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.

5

thanks a lot dude, it was a nice side by side comparison,

I really want that GraphQL API of dgraph to have all the features of the DQL, I
asked in another topic, but asking here too, is there any roadmap to see how the GraphQL API will evolve?

6

roadmap.dgraph.io

roadmap.dgraph.io

I believe the API is setup well to continue working with backwards compatibility with the options to expand in the areas it will need to grow.

Also I believe that as the official GraphQL spec expands that it will open more doors for Dgraph to do things that are not officially supported at this time, aka var blocks for one possibility. But I also think there is a potential to find areas to grow even within the official GraphQL spec such as I discussed on

1 Like