MichaelJCompton commented :
remove options in the update mutations. So it is possible to both add and remove edges.
This models the way it’s always worked in Dgraph.
There’s a reason to have these two behaviours : say for example I’ve got 1,000,000 followers, and the app wants to add one more follower - does it really need to fetch all 1,000,000 from Dgraph, add the one, and then send back a mutation for 1,000,000+1. That’s why there’s set and remove mutations in Dgraph. Set really only does addition of edges, remove does deletion of edges. That might not be made clear enough in the docs.
Often that correctly models the way an app attaches updates to clickable components in a UI: e.g. you click follow, it just sends an update set mutation for the one new follower. The mutation/UI doesn’t have to know the full current state, it just needs to know about the change it wants to make.
I wonder because GraphQL is another level of abstraction up, if there needs to be a third option for ‘just make it exactly as I have serialized it from my client’. E.g: the client doesn’t want to write code to work out what’s different, what’s been added, what’s been removed. etc. it just wants to make a mutation.
An example could be something like ‘tags’ on a post - the user has clicked around to add and remove some tags as part of editing a post. In the handler for save, the frontend dev doesn’t want to write code to compute the tags added and the tags removed, they just want to say that the post has been edited, now looks like this, please save it in the update mutation. On the backend we can open a transaction, compute the diffs and save as per the Dgraph set and remove primitives.