Building a Complete GraphQL Project

# CHAPTER 19

Building a Complete GraphQL Project #

1. Introduction #

2. Learning Objectives #

• Designed a complete MySQL database schema for Users and Tasks.

• Written a comprehensive GraphQL Schema (SDL).

• Implemented user registration and JWT authentication (Login).

• Created Queries to fetch lists and relational data.

• Created Mutations to Create, Update, and Delete data.

3. Project Overview #

• Users can register and log in.

• Authenticated users can create new tasks.

• Users can view their own tasks (but not other users' tasks).

• Users can mark tasks as completed.

• Users can delete tasks.

4. Database Setup (MySQL) #

CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(100) UNIQUE NOT NULL,
    password_hash VARCHAR(255) NOT NULL
);

CREATE TABLE tasks (
    id INT AUTO_INCREMENT PRIMARY KEY,
    user_id INT NOT NULL,
    title VARCHAR(255) NOT NULL,
    is_completed BOOLEAN DEFAULT FALSE,
    FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
);

5. The GraphQL Schema Blueprint #

type User {
  id: ID!
  name: String!
  email: String!
  tasks: [Task!]!
}

type Task {
  id: ID!
  title: String!
  isCompleted: Boolean!
  owner: User!
}

type AuthPayload {
  token: String!
  user: User!
}

type Query {
  me: User
  myTasks: [Task!]!
}

type Mutation {
  register(name: String!, email: String!, pass: String!): AuthPayload
  login(email: String!, pass: String!): AuthPayload
  createTask(title: String!): Task
  toggleTask(id: ID!, isCompleted: Boolean!): Task
  deleteTask(id: ID!): Boolean
}

6. Phase 1: Authentication Logic #

1. 1. Register Mutation: Your PHP resolver accepts the name, email, and password. It uses password_hash() to hash the password, inserts the user into MySQL, generates a JWT, and returns it.

1. 2. Login Mutation: The resolver looks up the email. Uses password_verify(). If valid, generates a JWT.

1. 3. Context Injection: In your index.php, read the HTTP Authorization header. Decode the JWT. If valid, set $context['userId'] = $decodedId;.

7. Phase 2: Queries (Reading Data) #

1. 1. me Resolver: Check if $context['userId'] exists. If yes, SELECT * FROM users WHERE id = ?. Return the row.

1. 2. myTasks Resolver: Ensure user is logged in. SELECT * FROM tasks WHERE user_id = ?. Return the array of tasks.

8. Phase 3: Resolving Relationships #

• Task -> owner: Take the $root['user_id'] and run SELECT * FROM users WHERE id = ?.

9. Phase 4: Mutations (Modifying Data) #

1. 1. createTask: Ensure logged in. INSERT INTO tasks (title, user_id) VALUES (?, ?). Fetch the newly created task and return it.

1. 2. toggleTask: Security Check! First, fetch the task. Check if $task['user_id'] === $context['userId']. If they don't match, throw an unauthorized error. If they match, UPDATE tasks SET is_completed = ? WHERE id = ?.

1. 3. deleteTask: Same security check as above. DELETE FROM tasks WHERE id = ?. Return true.

10. Testing the Application #

1. 1. Run the register mutation. Copy the Token.

1. 2. Add the token to the Playground's HTTP Headers: {"Authorization": "Bearer YOUR_TOKEN"}

1. 3. Run the createTask mutation.

1. 4. Run the myTasks query.

1. 5. Create a second user and try to deleteTask the first user's task. Verify that the server rejects it.

11. Mini Exercises #

1. 1. In Phase 4, why must we check $task['user_id'] === $context['userId'] before deleting?

1. 2. If the myTasks query returns an array of 5 tasks, how many times will the owner resolver execute if the client asks for the owner's name? (Hint: Think about N+1).

12. Coding Challenges #

13. Summary #

14. Next Chapter Recommendation #