Non-spec GraphQL Features

[BenW]

This is a continuation of the discussion started here:

What is Dgraph lacking?

Agree that this should not be immediate priority. But if you’re only making it available to users who specifically enable it, and make it clear that it could break things… then I don’t see the problem. Before Dgraph I was building a GraphQL API by hand with complete disregard for the spec, I just made it do whatever I needed it to do. Never ran into problems. What I would like is this amount of freedom and control over my API.

What is Dgraph lacking?

Following Anthony, GraphQL is like that for consistency/predictability and security. We cannot require an API language to do the work of a DB language. I think the custom query solves part of this problem. It’s basically what other DBs do when they add GraphQL to their code base in some way. However, there is still a lot that can be done under the spec. Nope, GraphQL foundation has total control of the Spec now. There are profound changes to ask. That’s too much pretentious for us to request…

What is Dgraph lacking?

This doesn’t sound very ambitious Michel! There’s no reason that Dgraph couldn’t be the most influential force on the GraphQL landscape. From my point of view Dgraph has a responsibility to put forward suggestions to the GraphQL Foundation, to ensure that the spec doesn’t prevent Dgraph from being able to achieve everything that’s technically possible. By the looks of it, adding feature requests is as simple as creating Github issues on their repo: https://github.com/graphql/graphql-spec/issues.…

What is Dgraph lacking?

This is probably bringing Dgraph full circle for those who have been around for a while. Be careful with what you wish for, just saying that if Dgraph is the only one that implement X feature in GraphQL then it probably won’t get much attention from the foundation because it is specifically language and database agnostic. https://github.com/dgraph-io/dgraph/issues/933#issue-228222037 This leads to one of those situations where it seems very deja vu to me and probably others.

I agree with the importance of spec-compliance. However, I also think there’s a lot of value in making it possible for Dgraph users to enable experimental non-spec features if they are willing to deal with the consequences. The benefits are:

• Give Dgraph users access to another layer of flexibility and functionality that could solve major problems for some users, and make it opt-in so it has no effect on Dgraph users who want to remain spec-compliant
• Create concept proofs to show to the GraphQL Foundation
• Demonstrate what Dgraph makes possible with GraphQL when it isn’t constrained by the spec

I think what I’m suggesting would only be a problem if these non-spec features were enabled by default.

Here are the experimental features that you can enable in iOS Safari:

Chrome’s experimental feature flags:

@amaster507

Be careful with what you wish for, just saying that if Dgraph is the only one that implement X feature in GraphQL then it probably won’t get much attention from the foundation because it is specifically language and database agnostic.

Can you think of an example of a non-spec feature that Dgraph could add that would be impossible to implement without Dgraph? Because the GraphQL spec merely describes how data should be requested and returned. While there are many types of queries that relational databases will struggle with, there isn’t any data that a relational database can’t return that a graph database can. The difference is difficulty and performance.

As for getting attention from the foundation, IMO this is less a technical problem and more a developer evangelism challenge.

EDIT: However, reading CONTRIBUTING.md it’s maybe not that simple, but still a worthwhile path to take IMO.

From https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md:

However, contributions that do meaningfully change the interpretation of the spec must follow an RFC (Request For Comments) process led by a champion through a series of stages intended to improve visibility , allow for discussion to reach the best solution, and arrive at consensus . This process becomes ever more important as GraphQL’s community broadens.

This would suggest that there is ample opportunity for new features to be added. It would just require persuasive and exhaustive debate. This seems like a great opportunity for Dgraph to become a GraphQL thought-leader and innovator.

• Performance is a feature GraphQL typically avoids syntax or behaviors that could jeopardize runtime efficiency, or that make demands of GraphQL services which cannot efficiently be fulfilled.

There’s definitely stuff that Dgraph can do that Postgres will struggle with. However, whether something jeopardizes runtime efficiency seems pretty arbitrary and quite open for debate.