มิวเทชัน GraphQL: การเปลี่ยนแปลงข้อมูล

You can now define types, resolvers, and run queries. But real APIs must also change data.

In GraphQL, every write goes through a mutation — the counterpart to a query.

The shapes look similar, but intent differs:

• Query: read data, no side effects, may run in parallel.
• Mutation: change data, executed sequentially top to bottom.

Mutations live under the special Mutation type and usually return the affected object.

For many fields, group arguments into an input type instead of a long argument list.

In Spring Boot, annotate the handler with @MutationMapping.

Returning the created or updated object lets the client immediately read back any fields it needs.

The same pattern covers all writes.

The resolver logic is plain Java; here is the core idea as a runnable snippet.

Mutations are the right place to enforce rules: reject empty titles, check permissions, ensure referenced records exist.

Return clear errors so clients can react meaningfully.

Unlike query fields, top-level mutation fields run one after another.

This guarantees that if a single request contains several mutations, earlier ones complete before later ones begin — important for consistency.

• Use input types for multi-field arguments.
• Return the affected object so clients can re-read fields.
• Validate and authorize inside resolvers.
• Name mutations as verbs: createBook, updateBook, deleteBook.

You learned to change data with GraphQL mutations.

• Define them under the Mutation type, often with input types.
• Implement with @MutationMapping in Spring Boot.
• They run sequentially and should validate and return the affected object.