Input validation patterns in GraphQL - Mini Project: Build & Apply

Input Validation Patterns in GraphQL

📖 Scenario: You are building a simple GraphQL API for a user registration system. You need to ensure that the inputs for creating a user are valid before saving them to the database.

🎯 Goal: Build a GraphQL schema with input validation patterns for user registration, including checks for username length, email format, and password strength.

📋 What You'll Learn

Create a GraphQL input type called CreateUserInput with fields username, email, and password.

Add validation rules for username to be at least 3 characters long.

Add validation rules for email to match a basic email pattern.

Add validation rules for password to be at least 8 characters long.

Create a mutation createUser that accepts CreateUserInput and returns a User type.

💡 Why This Matters

🌍 Real World

Input validation in GraphQL APIs is essential to prevent invalid or harmful data from entering your system, improving security and data quality.

💼 Career

Many backend developer roles require designing GraphQL schemas with proper input validation to build robust APIs.

1

Define the User type and CreateUserInput input type

Create a GraphQL User type with fields id (ID!), username (String!), email (String!). Then create an input type called CreateUserInput with fields username (String!), email (String!), and password (String!).

GraphQL

type User {
  id: ID!
  username: String!
  email: String!
}

input CreateUserInput {
  username: String!
  email: String!
  password: String!
}

# Your code here

Hint

Define the User type and CreateUserInput input type with the exact fields and types.

2

Add validation directives for username and email

Add validation directives to CreateUserInput: for username, add a directive to enforce minimum length of 3 characters. For email, add a directive to enforce a basic email pattern using a regex.

GraphQL

type User {
  id: ID!
  username: String!
  email: String!
}

input CreateUserInput {
  username: String! @length(min: 3)
  email: String! @pattern(regex: "^[^@\s]+@[^@\s]+\\.[^@\s]+$")
  password: String!
}

# Your code here

Hint

Use directives like @length(min: 3) and @pattern(regex: "...") on the input fields.

3

Add validation directive for password length

Add a validation directive to the password field in CreateUserInput to enforce a minimum length of 8 characters.

GraphQL

type User {
  id: ID!
  username: String!
  email: String!
}

input CreateUserInput {
  username: String! @length(min: 3)
  email: String! @pattern(regex: "^[^@\s]+@[^@\s]+\\.[^@\s]+$")
  password: String! @length(min: 8)
}

# Your code here

Hint

Add @length(min: 8) directive to the password field.

4

Create the createUser mutation

Add a mutation called createUser that accepts an argument input of type CreateUserInput! and returns a User!.

GraphQL

type User {
  id: ID!
  username: String!
  email: String!
}

input CreateUserInput {
  username: String! @length(min: 3)
  email: String! @pattern(regex: "^[^@\s]+@[^@\s]+\\.[^@\s]+$")
  password: String! @length(min: 8)
}

type Mutation {
  createUser(input: CreateUserInput!): User!
}

# Your code here

Hint

Define the Mutation type with the createUser mutation accepting CreateUserInput! and returning User!.

Practice

1. What is the main purpose of input validation in GraphQL schemas?

easy

A. To ensure data is safe and correct before processing

B. To speed up query execution

C. To automatically generate UI forms

D. To store data in multiple databases

Solution

1. Step 1: Understand input validation role

   Input validation checks data before it is saved or used to avoid errors or security issues.

2. Step 2: Identify main goal in GraphQL

   GraphQL uses input validation to keep data safe and correct before processing.

3. Final Answer:

   To ensure data is safe and correct before processing -> Option A

4. Quick Check:

   Input validation = data safety and correctness [OK]

Hint: Input validation means checking data before use [OK]

Common Mistakes:

• Confusing validation with performance optimization
• Thinking validation auto-generates UI
• Assuming validation stores data

2. Which of the following is a valid way to enforce input validation in a GraphQL schema?

easy

A. Using HTML tags in schema definitions

B. Writing SQL queries inside the schema

C. Adding CSS styles to input fields

D. Using custom scalar types for specific formats

Solution

1. Step 1: Review GraphQL schema capabilities

   GraphQL schemas can define custom scalar types to validate formats like email or date.

2. Step 2: Eliminate invalid options

   SQL queries, CSS, and HTML are unrelated to schema validation.

3. Final Answer:

   Using custom scalar types for specific formats -> Option D

4. Quick Check:

   Custom scalars = validation in schema [OK]

Hint: Custom scalars validate input formats in GraphQL [OK]

Common Mistakes:

• Confusing schema with UI styling
• Trying to embed SQL in schema
• Using HTML tags in schema definitions

3. Given this GraphQL input type and resolver snippet, what happens if the input 'username' is an empty string?

input UserInput {
  username: String!
}

resolver createUser(input: UserInput) {
  if (input.username.length === 0) {
    throw new Error('Username cannot be empty');
  }
  return saveUser(input);
}

medium

A. The resolver ignores the username field

B. The resolver throws an error and user is not saved

C. The user is saved with an empty username

D. The schema rejects the query before resolver runs

Solution

1. Step 1: Analyze resolver input check

   The resolver checks if username length is zero and throws an error if true.

2. Step 2: Understand effect of empty string input

   Empty string triggers the error, so user is not saved.

3. Final Answer:

   The resolver throws an error and user is not saved -> Option B

4. Quick Check:

   Empty username triggers error in resolver [OK]

Hint: Empty string triggers error in resolver check [OK]

Common Mistakes:

• Assuming schema rejects empty string automatically
• Thinking empty username is saved
• Ignoring resolver error handling

4. Identify the error in this GraphQL input validation snippet:

input ProductInput {
  price: Float!
}

resolver addProduct(input: ProductInput) {
  if (input.price < 0) {
    return 'Price must be positive';
  }
  saveProduct(input);
  return 'Product added';
}

medium

A. Returning a string error instead of throwing an error

B. Missing input type declaration

C. Using Float instead of Int for price

D. No validation for price being zero

Solution

1. Step 1: Check error handling in resolver

   The resolver returns a string on error instead of throwing an error, which may not stop execution properly.

2. Step 2: Understand proper error signaling

   Throwing an error is standard to halt processing and signal failure in GraphQL.

3. Final Answer:

   Returning a string error instead of throwing an error -> Option A

4. Quick Check:

   Errors should be thrown, not returned as strings [OK]

Hint: Throw errors, don't return error strings in resolvers [OK]

Common Mistakes:

• Returning error messages instead of throwing
• Confusing Float and Int types
• Ignoring zero price validation

5. You want to enforce that a user's email input is always lowercase and matches a valid email format in GraphQL. Which combination is the best approach?

hard

A. Use a directive to reject any uppercase letters without transformation

B. Only rely on GraphQL's String type without extra checks

C. Use a custom scalar for email format and transform input to lowercase in resolver

D. Validate email format in the database after saving

Solution

1. Step 1: Understand validation needs

   Email must be valid format and lowercase before saving or processing.

2. Step 2: Choose best GraphQL validation method

   Custom scalar can enforce format; resolver can transform input to lowercase.

3. Step 3: Evaluate other options

   Relying only on String misses validation; directives alone can't transform; database validation is late.

4. Final Answer:

   Use a custom scalar for email format and transform input to lowercase in resolver -> Option C

5. Quick Check:

   Custom scalar + resolver transform = best validation [OK]

Hint: Combine custom scalar and resolver for format and case [OK]

Common Mistakes:

• Skipping format validation
• Expecting directives to transform input
• Validating only after saving data