Real inverse relation on GraphQL schema

Users GraphQL
5

Hi, you’re actually bumping into some of the reasons why our GraphQL doesn’t use @reverse. Here’s the main reasons:

  • @reverse doesn’t allow mutations along the reverse edge. That was pretty much a show stopper in itself.
  • @reverse is always a list in the reverse direction. That creates some modelling issues in GraphQL and when combined with the point above, would restrict how you could model and mutate.
  • before we added the @dgraph directive, it would have added some complexity to query generation because it’d need a special case to work out that it’s a thing with a reverse and then to add the ~ edge instead of the real one.

I don’t think it’s ‘hacked in’ the way we did it. I actually think (because of the above) the other way of just leaning on reverse would have been the hack because it’d decrease what you can do with the API.
Where we’ve landed in the end, you get either choice.

I feel like there’s two things for us to do here:

  1. Seems like one of the biggest things we are missing is guidance. We don’t really have any good docs atm on how to handle running with GraphQL± and GraphQL at the same time. We also don’t have any docs on bulk loading with GraphQL.

  2. The GraphQL schema update has @dgraph but it doesn’t preserve some of the Dgraph things like @count and @reverse, so it wipes some bits of schema, which feels like what @Miaourt is bumping into. I wonder if the solution is to extend @dgraph so it can also take other args like @dgraph(pred: "Person.name", reverse: true) or @dgraph(pred: "Person.name", with: [reverse, count]).

Anything else that could help?

6 Likes