4

Currently in GraphQL JS implementation there is no standard way of returning a descriptive success message from mutation, such as "User created successfully", etc. My question has 2 parts:

  1. My thinking is that it is beneficial to return a success message from the API. That way the messages can be uniform across different clients (e.g. web and mobile). Clients don't have to implement their custom messages for each API call. But I'm not sure what the best practice is. Are there any drawbacks of returning a descriptive success message from mutation calls (besides increased response size)?

  2. If I decide to do it, is there a standard way in graphql-js to do this?

For example, is it possible to get back something like:

{
  data: {
    mutationName: {var1:"val1"}
  },
  messages: {
    mutationName:"User created successfully"
  }
}
Ed.
  • 1,409
  • 1
  • 9
  • 26
andr111
  • 2,864
  • 10
  • 32
  • 42

1 Answers1

4

Reasons not to do this

There is now a considerable amount of client code that depends on the shape of returned results being as they are. You would need to fork those if you were to implement your idea, at the cost of considerable effort, in order to benefit from your change.

Reason to stick with language spec as it is today

Meanwhile, what you want to achieve is (if I have understood you right) entirely achievable within the current spec.

Effective solution to stated problem

Why not do this (we'll make the mutation be user-creation):

schema {
  mutation: Mutation
  query: Query
}

type Mutation {
   newUser(params: NewUserInput): NewUserResult
}

input NewUserInput {
  # ...
}

type NewUserResult {
  successMessage(languageCode: LanguageCode): String
  newUser: User
}

# need to define Query, NewUserInput, User

This allows you to return a success message if that's what your system requires, without needing to change the spec of the GraphQL language.

If you really must...

(Source: graphql errors and status messages in graphql-js)

At least in express-graphql, there is a way to pass in extensions to it: https://github.com/graphql/express-graphql/blob/master/src/index.js#L89

Ed.
  • 1,409
  • 1
  • 9
  • 26
  • Thanks for the answer. This will not invalidate existing clients, because the shape of the response is not altered - it is enhanced by adding additional 'messages' field. I thought about solution similar to yours, but we weren't happy about it, because it means creating a new type for each type. We ended up utilizing formatResponse option. I'll share here once it's ready and tested. – andr111 Sep 29 '17 at 11:06