GraphQL+- poor support in GraphQL

[pawan (Pawan Rawal)]

Thanks for all the feedback @Luscha and for chipping in and explaining various bits here @amaster507.

@Luscha

but I think that being able to use the native expressiveness of GraphQL± in the GraphQL schema should be a major priority.

It is a major priority and also on the roadmap for the next quarter. You can expect support for this within the next month. This would allow you to easily be able to execute GraphQL+- queries (without making a HTTP request) to resolve certain fields.

@Luscha

Running the query above I thought that once dgraph returned a Person node to the GraphQL layer, it would’ve used it’s internal resolvers to continue the resolution of the inner fields (I’m still not an expert of GraphQL, but it was fair logic to me that once you have a Person node, GraphQL knew how to resolve the name field) but the response was not as expected:

So you are right here and @amaster507 also got this right. We expect fields resolved through @custom directive to return all the nested data for the field. So the flow of execution right now is like

1. Get data for fields from Dgraph that is asked by the user or is required for resolving custom fields.
2. Use that data to resolve custom fields.

So we only go one way right now, get data stored inside Dgraph and use that to resolve custom endpoints. We don’t do the other way around yet.

Now as you noticed, we could keep on going like this and then again do this recursively. That would give you an ability to join different Graphs (from your custom API and the one stored with Dgraph). We don’t do that right now but will be working on that as well in next couple of months.

Also, as @mrjn pointed out we are going to add support for executing Javascript code as part of the pipeline. The exact specification for this is yet to be worked out but here are some of the things it should allow.

• The ability to resolve a field through JS code given to us instead of resolving it over a HTTP/GraphQL endpoint.
• The ability to define pre and post hooks for resolving a query/mutation which give you the ability to transform/modify the result that you get from them.

We might add more bits to it as we start working on it. So yeah support for executing GraphQL± queries, traversing from one graph to another and back and also support for JS resolvers is all coming soon. In the meantime, we are also working on adding more documentation and examples.