Custom Mutations - Graphql

Let’s say we have an application about authors and posts. Logged in authors can add posts, but we want to do some input validation and add extra value when a post is added. The key types might be as follows.

type Author { ... }
type Post {
    id: ID:
    title: String
    text: String
    datePublished: DateTime
    author: Author

Dgraph generates an addPost mutation from those types, but we want to do something extra. We don’t want the author to come in with the mutation, that should get filled in from the JWT of the logged in user. Also, the datePublished shouldn’t be in the input; it should be set as the current time at point of mutation. Maybe we also have some community guidelines about what might constitute an offensive title or text in a post. Maybe users can only post if they have enough community credit.

We’ll need custom code to do all that, so we can write a custom function that takes in only the title and text of the new post. Internally, it can check that the title and text satisfy the guidelines and that this user has enough credit to make a post. If those checks pass, it then builds a full post object by adding the current time as the datePublished and adding the author from the JWT information it gets from the forward header. It can then call the addPost mutation constructed by Dgraph to add the post into Dgraph and returns the resulting post as its GraphQL output.

So as well as the types above, we need a custom mutation:

type Mutation {
    newPost(title: String!, text: String): Post @custom(http:{
        url: ""
        method: "POST",
        body: "{ postText: $text, postTitle: $title }"
        forwardHeaders: ["AuthHdr"]

Learn more

Find out more about how to turn off generated mutations and protecting mutations with authorization rules at:

This is a companion discussion topic for the original entry at

we may agree that in real-world applications, virtually all create/update type mutations would need some degree of validations,
so, tipically, most of auto-generated add* & update* shouldn’t be directly accessible from clients…
is there a way to prevent exposing overridden mutations on public schema ?
More generally, given there will likely be “internal” types that should not be exposed, not even as queryable, how to publicly hide portions of schema|queries|mutations ?

1 Like

I have the same question.

I didn’t find in docs a way to “hide” or “disable” some mutations & queries that are generated by default.

1 Like

So we are working on Expose only specific resolvers - #4 by amaster507 which would allow you to choose which resolvers to expose for a particular type. Would that work for you?

1 Like

I think it could work. Just for asking, Does Slash offers these feature (exposing certain resolvers)?

Slash is a hosted Dgraph backend service. The Dgraph package used by Slash is periodically updated. The feature of exposing certain resolvers is currently being worked upon in Dgraph and will soon be available in Slash as well.