Create mutation pattern in GraphQL - Time & Space Complexity
When we create new data using a GraphQL mutation, it is important to understand how the time it takes grows as we add more data.
We want to know how the work done changes when we create one or many items.
Analyze the time complexity of the following code snippet.
mutation CreateUser($input: CreateUserInput!) {
createUser(input: $input) {
id
name
email
}
}
This mutation creates a single user record with given details and returns the new user's information.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Creating one user record in the database.
- How many times: Exactly once per mutation call.
Each time we run this mutation, it creates one user. The work done grows directly with how many times we call it.
| Input Size (n) | Approx. Operations |
|---|---|
| 1 | 1 create operation |
| 10 | 10 create operations (if called 10 times) |
| 100 | 100 create operations (if called 100 times) |
Pattern observation: The work grows in a straight line with the number of creations.
Time Complexity: O(1)
This means creating one user takes a fixed amount of time, no matter what.
[X] Wrong: "Creating one user takes longer as the database grows bigger."
[OK] Correct: Usually, creating a single record is a simple operation that does not slow down noticeably as the database grows, because it does not scan all existing data.
Understanding how creating data scales helps you explain backend performance clearly and confidently in interviews.
"What if we changed this mutation to create multiple users at once? How would the time complexity change?"
Practice
mutation in GraphQL?Solution
Step 1: Understand GraphQL operation types
GraphQL has queries for reading data and mutations for changing data.Step 2: Identify mutation role
Mutations are used to create, update, or delete data in the database.Final Answer:
To create, update, or delete data in the database -> Option BQuick Check:
Mutation = change data [OK]
- Confusing mutations with queries
- Thinking mutations only fetch data
- Mixing schema definition with data operations
input of type CreateUserInput!?Solution
Step 1: Recall mutation syntax with variables
Variables in GraphQL mutations start with $ and have a colon before the type.Step 2: Check each option
mutation createUser($input: CreateUserInput!) { ... } correctly uses$input: CreateUserInput!. Others miss $ or colon.Final Answer:
mutation createUser($input: CreateUserInput!) { ... } -> Option AQuick Check:
Variables need $ and colon [OK]
- Omitting $ before variable name
- Missing colon between variable and type
- Using query instead of mutation keyword
mutation AddBook($book: BookInput!) {
addBook(input: $book) {
id
title
}
}What fields will the server return after running this mutation?
Solution
Step 1: Identify requested return fields
The mutation requestsidandtitlefields insideaddBook.Step 2: Understand GraphQL response
GraphQL returns only the fields explicitly requested, so onlyidandtitleare returned.Final Answer:
Only the id and title of the new book -> Option DQuick Check:
Requested fields = returned fields [OK]
- Assuming all fields return by default
- Expecting input object to be returned
- Thinking mutation returns no data
mutation CreatePost($post: PostInput!) {
createPost(post: $post) {
id
content
}
}Assuming the server expects the input argument to be named
input, not post.Solution
Step 1: Check argument name in mutation call
The mutation callscreatePost(post: $post), but server expectsinputargument.Step 2: Correct argument name
Changingposttoinputmatches server expectation and fixes error.Final Answer:
The argument name post should be input -> Option CQuick Check:
Argument names must match server schema [OK]
- Using wrong argument name in mutation call
- Confusing variable name with argument name
- Changing mutation keyword incorrectly
name and email. Which mutation correctly uses input variables and requests the new user's id and email in the response?Solution
Step 1: Check variable declaration and usage
mutation AddUser($input: UserInput!) { addUser(input: $input) { id email } } correctly declares$input: UserInput!and uses it asinput: $input.Step 2: Verify requested return fields
mutation AddUser($input: UserInput!) { addUser(input: $input) { id email } } requestsidandemail, matching the question requirement.Final Answer:
mutation AddUser($input: UserInput!) { addUser(input: $input) { id email } } -> Option AQuick Check:
Correct variable and requested fields = mutation AddUser($input: UserInput!) { addUser(input: $input) { id email } } [OK]
- Omitting $ in variable declaration or usage
- Requesting wrong fields in response
- Using wrong argument names
Ready to prove it?
Pass the test and this pattern moves unknown
