This is a continuation of the discussion started here:
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:
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.
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.