This depends a lot on the culture of the company you work for. If you already have engineers using GraphQL, go to GraphQL. If you want to build something strictly related to the main language of Dgraph. Go from
GraphQL+-. But you must choose one of them and use the second only as an extra option for internal cases.
I think that depending on the choice, the two languages complement each other.
The advantages of using GraphQL are that it has a giant ecosystem out there. Take for example Apollo GraphQL. They have created numerous tools for GraphQL that work with Dgraph’s GraphQL out of the box.
Personally, I’m a fan of Apollo GraphQL.
GraphQL+- in practice are sister languages. If you learn to use one, learning to use the other will not be so difficult.
With GraphQL your front-end team will be always happy xD
GraphQL in Dgraph was created so that you do not have to worry about creating a GraphQL API manually. Making your life easier when building an application. You gain speed with this feature and less hassle of having to align
GraphQL+- with your GraphQL API.
GraphQL does not support all functions and benefits of
GraphQL+-. There are no variables, recurse queries, etc. However, the core engineers are working to ensure good alignment with the two languages.
It is a rich language, thought to be something that goes beyond GraphQL and inspired by GraphQL. It follows the needs of the Dgraph database. GraphQL, on the other hand, has to be a broad language that meets the needs of various DBs and APIs out there.
GraphQL+- you can make complex queries that GraphQL would not be able to do due to its well-defined and standardized Specs in context to the variety of existing DBs and services.
Your queries have direct access to the dataset. There are no limits to what you can do.
You need to learn the nuances of that language. Perhaps for some people, this is bad. Having to learn something more.
Although inspired, it is not directly compatible with GraphQL Specs.