Question: What will happen with GraphQL± ? will all great GraphQL± features (Facets, Aggregation, Transactions, Upserts, Math functions, i18n features…) All be modelled in GraphQL or will some of these great features be missing forever in DGraph? I’m convinced that all of these features can be expressed in pure GraphQL syntax, since every GraphQL query or mutation operation in the end is nothing more than a parametrized function call to a remote endpoint. So if a GraphQL± feature can be expressed as a function expression, it is pure GraphQL “compatible”…
Slash GraphQL supports GraphQL± with caveats, refer Slash GraphQL Release July 28 2020 & Advanced Queries documentation & GraphQL+- poor support in GraphQL - #9 by pawan discussion.
RFCs:
- Implementing Geo features in GraphQL
- Supporting GraphQL+- queries in GraphQL
- GraphQL+- -> Spec Compliant GraphQL
Last one might interest @pmualaba, as @michaelcompton goes into detail about each of the feature of GraphQL± and how easy, hard, or impossible the translation to spec compliant GraphQL will be.
P.S. The answer to this question must be pinned globally IMO as it’s FAQ. I asked it several times myself!
GraphQL± isn’t going anywhere as its much more powerful than the GraphQL API. Though we do want to make the GraphQL as powerful as possible. We’ll follow a two-step approach here.
-
Allow the user to resolve GraphQL queries/fields based on the result of a GraphQL± query using
@custom
directive. This is already available in master and you can look at the docs for this at https://graphql.dgraph.io/doc/custom/graphqlpm. We’ll continue iterating and improving this. This gives the user a lot of power as they can execute ± queries through the GraphQL API. -
Introduce GraphQL± features natively into GraphQL - We plan to bring as many GraphQL± features as possible into GraphQL. We are working with priority on this and would be adding support for all the features that can be ported natively to GraphQL.