问题
In the Apollo documentation it talks about using Mutation Response Types where you would return a response that included keys for code, success, message, as well as keys for the specific data that was change. i.e. a user.
EXAMPLE:
interface MutationResponse {
code: String!
success: Boolean!
message: String!
}
type UpdateUserMutationResponse implements MutationResponse {
code: String!
success: Boolean!
message: String!
user: User
}
We have been using this approach for some time now. We also adopted this approach for our queries and have a Query Response Type for each query.
If a user cannot be found for example, the response returns the appropriate details to the client.
Throwing errors from our microservices down the pipe to the client makes things allot more messy and difficult to reason about. We have started reworking one of our APIs to not use Query Response Types and dealing with errors, etc. has become way more complex.
So my question is, what would be the downsides of using a Query Response Type, in addition to Mutation Response Types? We can't decide if we should replace the Query Response Types or leave them be.
来源：https://stackoverflow.com/questions/54657425/what-are-the-downside-to-having-query-response-types-in-graphql