Components:

• User Interface (UI): A web-based application providing visual and textual schema editing capabilities.
• Backend Schema Service: The core API responsible for managing schema definitions, handling user requests, and orchestrating other backend services.
• Database: Stores the structured schema definitions, user projects, and metadata.
• Schema Validation Service: A dedicated module or service responsible for parsing, validating, and linting GraphQL schemas.
• Code Generation Service: A module or service responsible for generating various outputs (SDL, resolver stubs, integration examples) based on the defined schema.

3. Core Architectural Components & Features

3.1. Frontend Architecture (User Interface)

The frontend will be a Single Page Application (SPA) designed for responsiveness and interactivity.

• Framework: React (with TypeScript) for component-based development.
• State Management: Zustand or React Context API for lightweight, efficient state management.
• UI Library: Chakra UI or Material-UI for consistent, accessible components.
• Visualization Library: React Flow or D3.js for interactive graph visualization of schema relationships.
• Code Editor Component: Monaco Editor (VS Code's editor) for a rich, syntax-highlighting SDL editor experience.
• Key Features:

* Visual Schema Editor: Drag-and-drop interface for creating and connecting types, fields, and relationships.

* SDL Editor: Real-time syntax highlighting, auto-completion, and error checking for direct SDL editing.

* Schema Explorer: Tree-view navigation of the entire schema.

* Property Panels: Context-sensitive panels for editing type/field properties (name, description, type, nullability, arguments, directives).

* Project Management: Create, open, save, and manage multiple schema projects.

* Version History Viewer: Visualize and revert to previous schema versions.

3.2. Backend Architecture (API & Services)

The backend will be built as a set of microservices or a well-modularized monolithic application, exposing a RESTful or GraphQL API to the frontend.

• Framework: Node.js with Express/NestJS or Python with FastAPI/Django. (Node.js preferred for JavaScript ecosystem alignment).
• API Gateway: For routing, authentication, and rate limiting (if microservices are adopted).
• Core Schema Service:

* CRUD operations for schema components (types, fields, directives, queries, mutations, subscriptions).

* Manages project lifecycles.

* Handles user authentication and authorization.

* Orchestrates calls to Validation and Code Generation services.

• Schema Validation Service:

* Parses incoming SDL or internal schema representation.

* Performs GraphQL specification compliance checks.

* Implements customizable linting rules (e.g., naming conventions).

* Provides detailed error and warning messages.

* Leverages existing libraries like graphql-js for parsing and validation.

• Code Generation Service:

* Generates GraphQL SDL from the internal schema model.

* Generates boilerplate resolver functions for various backend languages (e.g., JavaScript, Python, Java, Go).

* Generates client-side integration examples (e.g., Apollo Client, Relay, plain fetch with queries/mutations).

* Supports custom templates for generation.

• Authentication & Authorization: JWT-based authentication for user sessions, role-based access control (RBAC) for project permissions.

3.3. Data Model for Schema Storage

The internal representation of the GraphQL schema is crucial for manipulation and generation. A relational database is suitable for structured storage of schema components and their relationships.

• Database: PostgreSQL (preferred for its JSONB support and strong relational capabilities).
• Key Entities:

* Project: id, name, description, ownerId, latestSchemaVersionId.

* SchemaVersion: id, projectId, sdlContent, jsonContent (internal representation), createdAt, createdBy.

* GraphQLType: id, schemaVersionId, name, kind (OBJECT, SCALAR, ENUM, INTERFACE, UNION, INPUT_OBJECT), description, fieldsJson (JSONB for complex field properties).

* GraphQLField: id, typeId, name, typeRefId (points to another GraphQLType), isList, isNullable, description, argumentsJson (JSONB for arguments).

* GraphQLArgument: id, fieldId, name, typeRefId, isList, isNullable, defaultValue.

* GraphQLDirective: id, schemaVersionId, name, locations, argumentsJson.

* User: id, username, email, passwordHash.

* ProjectMembership: projectId, userId, role (OWNER, EDITOR, VIEWER).

4. Detailed Feature Breakdown & Implementation Strategy

4.1. Schema Definition (Types, Queries, Mutations, Subscriptions)

• Types:

* Object Types: Define name, description, fields. Each field has a name, type (scalar, custom object, enum, interface), nullability, and arguments.

* Scalar Types: Support built-in scalars (String, Int, Float, Boolean, ID) and allow defining custom scalars.

* Enum Types: Define name, description, and enum values.

* Interface Types: Define name, description, and fields that implementing types must include.

* Union Types: Define name, description, and member types.

* Input Object Types: Define name, description, and input fields.

• Queries, Mutations, Subscriptions:

* Treated as special Object Types (Query, Mutation, Subscription) with their respective fields representing the root operations.

* The designer will explicitly guide users to define fields under these root types.

4.2. Resolvers and Integration Examples

This is where the designer moves beyond just schema definition to practical implementation guidance.

• Resolver Mapping:

* For each field, allow users to associate metadata about its intended resolver (e.g., data source type: REST API, Database, Microservice; endpoint/table name; mapping logic). This metadata is stored but not executed by the designer.

* Provide a "Resolver Hints" panel where users can add notes or pseudocode for resolver logic.

• Resolver Code Generation:

* Based on the schema and resolver mapping metadata, generate boilerplate resolver functions in chosen languages (e.g., JavaScript with Apollo Server, Python with Graphene).

* Include basic data fetching examples (e.g., return db.users.find({ id: parent.id })).

• Client Integration Examples:

* Generate example GraphQL queries, mutations, and subscriptions based on the defined schema.

* Provide client-side code snippets for popular libraries (e.g., React with Apollo Client, Vue with Vue Apollo).

* Show how to pass variables, handle loading states, and display data.

• Mock Server Generation (Future): Generate a simple mock GraphQL server that responds with dummy data based on the schema, allowing frontend teams to start development immediately.

4.3. Schema Validation & Best Practices

• Syntax Validation: Real-time checking against GraphQL SDL specification.
• Semantic Validation: Ensure type references are valid, fields don't conflict, etc.
• Linting & Best Practices:

* Naming conventions (e.g., PascalCase for types, camelCase for fields/args).

* Description requirements for types and fields.

* Avoidance of N+1 issues (guidance, not automatic fix).

* Use of directives for common patterns (e.g., @deprecated).

5. Technology Stack Recommendations

• Frontend:

* Framework: React 18+

* Language: TypeScript

* UI Toolkit: Chakra UI / Material-UI

* Visualization: React Flow / D3.js

* Code Editor: Monaco Editor

• Backend:

* Language: Node.js

* Framework: NestJS (for structured, modular application)

* Database ORM: TypeORM / Prisma

* Authentication: Passport.js / custom JWT implementation

• Database: PostgreSQL (with JSONB for flexible schema metadata)
• Caching: Redis (for session management, frequently accessed schema parts)
• Deployment: Docker, Kubernetes (for containerization and orchestration)
• Cloud Platform: AWS / Google Cloud Platform / Azure (provider-agnostic design)
• Version Control: Git
• CI/CD: GitHub Actions / GitLab CI / Jenkins

6. Scalability, Performance & Security Considerations

6.1. Scalability & Performance

• Database Indexing: Properly index Project, SchemaVersion, and GraphQLType tables for fast lookups.
• Caching: Implement caching for frequently accessed schema parts or generated outputs.
• Asynchronous Processing: Offload heavy operations like complex schema validation or code generation to background workers/queues.
• Frontend Optimization: Lazy loading components, virtualization for large lists/graphs, efficient state updates.
• Horizontal Scaling: Design backend services to be stateless where possible to allow for easy horizontal scaling.

6.2. Security

• Authentication & Authorization: Implement robust JWT-based authentication and RBAC for project access.
• Data Encryption: Encrypt sensitive data at rest (e.g., database backups) and in transit (HTTPS/TLS).
• Input Validation: Strict validation on all user inputs to prevent injection attacks (XSS, SQL injection).
• Rate Limiting: Protect against brute-force attacks and API abuse.
• Regular Security Audits: Perform periodic security reviews and vulnerability scanning.
• Least Privilege: Ensure services and users only have access to resources strictly necessary for their function.

7. Deployment Strategy

• Containerization: All services (frontend, backend, database) will be containerized using Docker.
• Orchestration: Kubernetes will be used for managing and scaling containers in a production environment.
• CI/CD Pipeline:

1. Code commit triggers CI pipeline.

2. Automated tests (unit, integration, end-to-end).

3. Docker image building and tagging.

4. Image pushing to a container registry (e.g., ECR, GCR, Docker Hub).

5. CD pipeline deploys new images to staging/production environments with zero downtime strategies (e.g., rolling updates).

• Environment Management: Separate environments for

This deliverable outlines a comprehensive GraphQL schema design for an e-commerce platform, including type definitions, queries, mutations, subscriptions, example resolvers, and integration patterns for both server and client-side applications. This design prioritizes clarity, scalability, and maintainability, serving as a robust foundation for your GraphQL API.

1. GraphQL Schema Definition Language (SDL)

This section defines the core structure of your GraphQL API using the Schema Definition Language (SDL). It includes custom scalars, enums, object types, input types, and the root Query, Mutation, and Subscription types.

# Custom Scalar for representing date and time values
scalar DateTime

# Enums for fixed sets of values
enum UserRole {
  ADMIN
  CUSTOMER
}

enum ProductStatus {
  ACTIVE
  INACTIVE
  DRAFT
  ARCHIVED
}

enum OrderStatus {
  PENDING
  PROCESSING
  SHIPPED
  DELIVERED
  CANCELLED
  REFUNDED
}

# --- Core Types ---

type User {
  id: ID!
  username: String!
  email: String!
  role: UserRole!
  addresses: [Address!]
  orders(page: Int = 1, pageSize: Int = 10): OrderConnection!
  reviews: [Review!]
  createdAt: DateTime!
  updatedAt: DateTime!
}

type Address {
  id: ID!
  street: String!
  city: String!
  state: String!
  zipCode: String!
  country: String!
  isDefault: Boolean
}

type Category {
  id: ID!
  name: String!
  description: String
  products(page: Int = 1, pageSize: Int = 10): ProductsConnection!
  createdAt: DateTime!
  updatedAt: DateTime!
}

type Product {
  id: ID!
  name: String!
  description: String
  price: Float!
  imageUrl: String
  status: ProductStatus!
  category: Category!
  reviews(page: Int = 1, pageSize: Int = 10): ReviewsConnection!
  createdAt: DateTime!
  updatedAt: DateTime!
}

type Review {
  id: ID!
  rating: Int! # 1-5 stars
  comment: String
  user: User!
  product: Product!
  createdAt: DateTime!
}

type OrderItem {
  id: ID!
  product: Product!
  quantity: Int!
  priceAtOrder: Float! # Price at the time of order
}

type Order {
  id: ID!
  user: User!
  items: [OrderItem!]!
  totalAmount: Float!
  status: OrderStatus!
  shippingAddress: Address!
  createdAt: DateTime!
  updatedAt: DateTime!
}

# --- Pagination Types (Relay-style connection for consistency) ---

type PageInfo {
  hasNextPage: Boolean!
  hasPreviousPage: Boolean!
  startCursor: String
  endCursor: String
  # For offset-based pagination fallback
  currentPage: Int
  totalPages: Int
  totalItems: Int
}

type UserEdge {
  node: User!
  cursor: String!
}

type UsersConnection {
  pageInfo: PageInfo!
  edges: [UserEdge!]!
  nodes: [User!]! # Convenience field for simpler consumption
}

type ProductEdge {
  node: Product!
  cursor: String!
}

type ProductsConnection {
  pageInfo: PageInfo!
  edges: [ProductEdge!]!
  nodes: [Product!]!
}

type OrderEdge {
  node: Order!
  cursor: String!
}

type OrderConnection {
  pageInfo: PageInfo!
  edges: [OrderEdge!]!
  nodes: [Order!]!
}

type ReviewEdge {
  node: Review!
  cursor: String!
}

type ReviewsConnection {
  pageInfo: PageInfo!
  edges: [ReviewEdge!]!
  nodes: [Review!]!
}

# --- Mutation Response Types ---

# Generic response for mutations that don't return a specific object
type MutationResponse {
  success: Boolean!
  message: String
  code: String # Optional error code or success code
}

# --- Input Types for Mutations ---

input CreateUserInput {
  username: String!
  email: String!
  password: String!
  role: UserRole = CUSTOMER # Default role
}

input UpdateUserInput {
  username: String
  email: String
  password: String
  role: UserRole
  # Potentially add fields for updating addresses
}

input CreateAddressInput {
  street: String!
  city: String!
  state: String!
  zipCode: String!
  country: String!
  isDefault: Boolean = false
}

input UpdateAddressInput {
  street: String
  city: String
  state: String
  zipCode: String
  country: String
  isDefault: Boolean
}

input CreateCategoryInput {
  name: String!
  description: String
}

input UpdateCategoryInput {
  name: String
  description: String
}

input CreateProductInput {
  name: String!
  description: String
  price: Float!
  imageUrl: String
  categoryId: ID!
  status: ProductStatus = DRAFT # Default status
}

input UpdateProductInput {
  name: String
  description: String
  price: Float
  imageUrl: String
  categoryId: ID
  status: ProductStatus
}

input OrderItemInput {
  productId: ID!
  quantity: Int!
}

input PlaceOrderInput {
  items: [OrderItemInput!]!
  shippingAddressId: ID!
}

input CreateReviewInput {
  rating: Int!
  comment: String
}

# --- Root Query Type (Read Operations) ---

type Query {
  # User related queries
  viewer: User # The authenticated user
  user(id: ID!): User
  users(
    after: String
    before: String
    first: Int
    last: Int
    page: Int = 1
    pageSize: Int = 10
  ): UsersConnection!

  # Category related queries
  category(id: ID!): Category
  categories(
    after: String
    before: String
    first: Int
    last: Int
    page: Int = 1
    pageSize: Int = 10
  ): ProductsConnection! # Renamed from categories to avoid confusion for pagination

  # Product related queries
  product(id: ID!): Product
  products(
    categoryId: ID
    search: String
    status: ProductStatus
    minPrice: Float
    maxPrice: Float
    after: String
    before: String
    first: Int
    last: Int
    page: Int = 1
    pageSize: Int = 10
  ): ProductsConnection!

  # Order related queries
  order(id: ID!): Order
  orders(
    userId: ID
    status: OrderStatus
    after: String
    before: String
    first: Int
    last: Int
    page: Int = 1
    pageSize: Int = 10
  ): OrderConnection!
}

# --- Root Mutation Type (Write Operations) ---

type Mutation {
  # User mutations
  createUser(input: CreateUserInput!): User!
  updateUser(id: ID!, input: UpdateUserInput!): User!
  deleteUser(id: ID!): MutationResponse!
  addAddressToUser(userId: ID!, input: CreateAddressInput!): Address!
  updateUserAddress(addressId: ID!, input: UpdateAddressInput!): Address!
  deleteUserAddress(addressId: ID!): MutationResponse!

  # Category mutations
  createCategory(input: CreateCategoryInput!): Category!
  updateCategory(id: ID!, input: UpdateCategoryInput!): Category!
  deleteCategory(id: ID!): MutationResponse!

  # Product mutations
  createProduct(input: CreateProductInput!): Product!
  updateProduct(id: ID!, input: UpdateProductInput!): Product!
  deleteProduct(id: ID!): MutationResponse!
  updateProductStatus(id: ID!, status: ProductStatus!): Product!

  # Order mutations
  placeOrder(input: PlaceOrderInput!): Order!
  updateOrderStatus(id: ID!, status: OrderStatus!): Order!
  cancelOrder(id: ID!): Order! # Sets status to CANCELLED

  # Review mutations
  createReview(productId: ID!, input: CreateReviewInput!): Review!
  updateReview(id: ID!, input: CreateReviewInput!): Review! # Reusing input for simplicity
  deleteReview(id: ID!): MutationResponse!
}

# --- Root Subscription Type (Real-time Operations) ---

type Subscription {
  newOrder: Order! # Notifies when a new order is placed
  orderStatusUpdated(orderId: ID!): Order! # Notifies when a specific order's status changes
  productPriceUpdated(productId: ID!): Product! # Notifies when a specific product's price changes
  productStockUpdated(productId: ID!): Product! # Notifies when a specific product's stock changes (if stock was part of product type)
  reviewAdded(productId: ID!): Review! # Notifies when a new review is added to a product
}

2. Resolver Implement

GraphQL Schema Design: Project Management System

This document outlines a comprehensive GraphQL schema for a Project Management System, encompassing types, queries, mutations, subscriptions, resolver strategies, and client integration examples. This design aims to provide a flexible and efficient API for managing users, projects, tasks, and comments.

1. Introduction

This deliverable provides a detailed specification for a GraphQL API schema, designed to support a robust Project Management System. The schema is defined using GraphQL Schema Definition Language (SDL) and covers all essential operations, including data retrieval (Queries), data modification (Mutations), and real-time updates (Subscriptions). We also provide insights into resolver implementation and practical client integration examples.

2. Schema Overview

The Project Management System schema is structured around the following core entities:

• User: Represents an individual user within the system.
• Project: Represents a collection of tasks, assigned to users.
• Task: Represents a specific unit of work, belonging to a project and assigned to a user.
• Comment: Represents feedback or discussion related to a task.

The schema includes:

• Object Types: Custom types like User, Project, Task, Comment.
• Enum Types: UserRole, TaskStatus for constrained fields.
• Input Types: Dedicated types for mutation arguments, promoting reusability and clarity.
• Root Types: Query for data fetching, Mutation for data modification, and Subscription for real-time data updates.

3. GraphQL Schema Definition Language (SDL)

Below is the complete GraphQL Schema Definition Language (SDL) for the Project Management System.

# --- Scalar Types ---
# ID: A unique identifier, often used to refetch an object or as key for a cache.
# String: A UTF‐8 character sequence.
# Int: A signed 32‐bit integer.
# Float: A signed double‐precision floating‐point value.
# Boolean: true or false.

# Custom Scalar for representing date-time values (e.g., ISO 8601 string)
scalar DateTime

# --- Enum Types ---

enum UserRole {
  ADMIN
  MANAGER
  MEMBER
  GUEST
}

enum TaskStatus {
  OPEN
  IN_PROGRESS
  COMPLETED
  BLOCKED
  PENDING_REVIEW
}

# --- Object Types ---

type User {
  id: ID!
  username: String!
  email: String!
  firstName: String
  lastName: String
  role: UserRole!
  createdAt: DateTime!
  updatedAt: DateTime!
  projects: [Project!]!
  tasks: [Task!]!
  comments: [Comment!]!
}

type Project {
  id: ID!
  name: String!
  description: String
  status: String! # e.g., "Active", "Archived", "On Hold"
  startDate: DateTime
  endDate: DateTime
  manager: User!
  members: [User!]!
  tasks(status: TaskStatus): [Task!]! # Filter tasks within a project
  createdAt: DateTime!
  updatedAt: DateTime!
}

type Task {
  id: ID!
  title: String!
  description: String
  status: TaskStatus!
  priority: Int # e.g., 1 (high) to 5 (low)
  dueDate: DateTime
  project: Project!
  assignedTo: User!
  createdBy: User!
  comments: [Comment!]!
  createdAt: DateTime!
  updatedAt: DateTime!
}

type Comment {
  id: ID!
  content: String!
  task: Task!
  author: User!
  createdAt: DateTime!
  updatedAt: DateTime!
}

# --- Input Types for Mutations ---

input CreateUserInput {
  username: String!
  email: String!
  firstName: String
  lastName: String
  role: UserRole = MEMBER # Default role
}

input UpdateUserInput {
  username: String
  email: String
  firstName: String
  lastName: String
  role: UserRole
}

input CreateProjectInput {
  name: String!
  description: String
  status: String
  startDate: DateTime
  endDate: DateTime
  managerId: ID!
  memberIds: [ID!]!
}

input UpdateProjectInput {
  name: String
  description: String
  status: String
  startDate: DateTime
  endDate: DateTime
  managerId: ID
  memberIds: [ID!]
}

input CreateTaskInput {
  title: String!
  description: String
  status: TaskStatus = OPEN # Default status
  priority: Int
  dueDate: DateTime
  projectId: ID!
  assignedToId: ID!
  createdById: ID! # The user creating the task
}

input UpdateTaskInput {
  title: String
  description: String
  status: TaskStatus
  priority: Int
  dueDate: DateTime
  projectId: ID
  assignedToId: ID
}

input CreateCommentInput {
  content: String!
  taskId: ID!
  authorId: ID!
}

# --- Root Query Type ---

type Query {
  me: User # Get the currently authenticated user
  
  user(id: ID!): User
  users(role: UserRole, search: String): [User!]!

  project(id: ID!): Project
  projects(status: String, search: String): [Project!]!

  task(id: ID!): Task
  tasks(projectId: ID!, status: TaskStatus, assignedToId: ID): [Task!]!

  comment(id: ID!): Comment
  comments(taskId: ID!): [Comment!]!
}

# --- Root Mutation Type ---

type Mutation {
  # User Mutations
  createUser(input: CreateUserInput!): User!
  updateUser(id: ID!, input: UpdateUserInput!): User!
  deleteUser(id: ID!): Boolean! # Returns true if deletion was successful

  # Project Mutations
  createProject(input: CreateProjectInput!): Project!
  updateProject(id: ID!, input: UpdateProjectInput!): Project!
  deleteProject(id: ID!): Boolean!

  # Task Mutations
  createTask(input: CreateTaskInput!): Task!
  updateTask(id: ID!, input: UpdateTaskInput!): Task!
  deleteTask(id: ID!): Boolean!

  # Comment Mutations
  createComment(input: CreateCommentInput!): Comment!
  updateComment(id: ID!, content: String!): Comment!
  deleteComment(id: ID!): Boolean!
}

# --- Root Subscription Type ---

type Subscription {
  taskUpdated(projectId: ID!): Task! # Notifies when a task in a specific project is updated
  commentAdded(taskId: ID!): Comment! # Notifies when a new comment is added to a specific task
}

4. Detailed Schema Breakdown

4.1. Scalar Types

• ID: A unique identifier, serialized as a String.
• String: Standard text string.
• Int: Standard integer.
• Boolean: True or false.
• DateTime: A custom scalar type used to represent date and time values. It is recommended to serialize this as an ISO 8601 string (e.g., "2023-10-27T10:00:00Z").

4.2. Enum Types

• UserRole:

* ADMIN: Full administrative access.

* MANAGER: Project management capabilities.

* MEMBER: Standard user, can perform tasks.

* GUEST: Limited view-only access.

• TaskStatus:

* OPEN: Task is newly created.

* IN_PROGRESS: Task is actively being worked on.

* COMPLETED: Task is finished.

* BLOCKED: Task cannot proceed due to an impediment.

* PENDING_REVIEW: Task is awaiting review.

4.3. Object Types

• User:

* id: ID!: Unique identifier.

* username: String!: Unique username.

* email: String!: User's email address.

* firstName: String: User's first name.

* lastName: String: User's last name.

* role: UserRole!: The role of the user (e.g., ADMIN, MEMBER).

* createdAt: DateTime!: Timestamp of user creation.

* updatedAt: DateTime!: Timestamp of last update.

* projects: [Project!]!: List of projects the user is involved in (as manager or member).

* tasks: [Task!]!: List of tasks assigned to the user.

* comments: [Comment!]!: List of comments authored by the user.

• Project:

* id: ID!: Unique identifier.

* name: String!: Name of the project.

* description: String: Detailed description of the project.

* status: String!: Current status of the project (e.g., "Active", "Archived").

* startDate: DateTime: Project start date.

* endDate: DateTime: Project end date.

* manager: User!: The user responsible for managing the project.

* members: [User!]!: List of users involved in the project.

* tasks(status: TaskStatus): [Task!]!: List of tasks within the project. Can be filtered by status.

* createdAt: DateTime!: Timestamp of project creation.

* updatedAt: DateTime!: Timestamp of last update.

• Task:

* id: ID!: Unique identifier.

* title: String!: Short title for the task.

* description: String: Detailed description of the task.

* status: TaskStatus!: Current status of the task.

* priority: Int: Priority level (e.g., 1-5).

* dueDate: DateTime: Deadline for the task.

* project: Project!: The project this task belongs to.

* assignedTo: User!: The user responsible for completing the task.

* createdBy: User!: The user who created this task.

* comments: [Comment!]!: List of comments associated with the task.

* createdAt: DateTime!: Timestamp of task creation.

* updatedAt: DateTime!: Timestamp of last update.

• Comment:

* id: ID!: Unique identifier.

* content: String!: The text content of the comment.

* task: Task!: The task this comment belongs to.

* author: User!: The user who authored the comment.

* createdAt: DateTime!: Timestamp of comment creation.

* updatedAt: DateTime!: Timestamp of last update.

4.4. Input Types

Input types are used for passing complex objects as arguments to mutations, improving readability and reusability.

• CreateUserInput: Used for createUser mutation.
• UpdateUserInput: Used for updateUser mutation.
• CreateProjectInput: Used for createProject mutation.
• UpdateProjectInput: Used for updateProject mutation.
• CreateTaskInput: Used for createTask mutation.
• UpdateTaskInput: Used for updateTask mutation.
• CreateCommentInput: Used for createComment mutation.

4.5. Root Query Type

The Query type defines all entry points for reading data from the graph.

• me: User: Retrieves the currently authenticated user's profile.
• user(id: ID!): User: Retrieves a single user by their ID.
• users(role: UserRole, search: String): [User!]!: Retrieves a list of users, with optional filtering by role or search string (e.g., username, email).
• project(id: ID!): Project: Retrieves a single project by its ID.
• projects(status: String, search: String): [Project!]!: Retrieves a list of projects, with optional filtering by status or search string (e.g., project name).
• task(id: ID!): Task: Retrieves a single task by its ID.