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: Issues · graphql/graphql-spec · GitHub.
Seems like this is similar to how things work with the HTML and CSS specs:
- Browser vendors come up with new features
- They submit feature requests to the W3C
- A JS or CSS feature that is only available in xyz browser becomes popular with developers
- Developers build polyfills so they can start using the feature in their projects
- W3C recognises that the feature is required, adds it to the spec
- Other browsers implement the feature because it’s now in the spec
That being said, I don’t know enough about what the spec is actually preventing to be able to make informed comments about this.
EDIT: In fact this could be incredible marketing opportunity for Dgraph—to implement experimental features that show what is really possible with GraphQL if you put a v12 engine inside it. Experimental features can be only be used with a special build, or with ENV flags. Build some demos of the feature, create feature request on the Spec repo with links to the demos. Get the GraphQL community talking about it. Good way to demonstrate what’s really possible with GraphQL, and that Dgraph is what makes it possible.