This document outlines the architectural plan for a robust GraphQL Schema Designer application and provides a comprehensive study plan for mastering GraphQL schema design principles.
This section details the proposed architecture for a sophisticated GraphQL Schema Designer application, designed to facilitate the creation, visualization, validation, and generation of GraphQL schemas.
The GraphQL Schema Designer is envisioned as a web-based application that empowers developers and architects to visually design and manage complex GraphQL schemas. It will support defining types, queries, mutations, subscriptions, and their relationships, offering features like real-time validation, code generation, and collaboration. The architecture aims for scalability, maintainability, and extensibility.
The application will provide the following core features:
The GraphQL Schema Designer will follow a client-server architecture, primarily utilizing a modern web stack.
graph TD
A[User] -->|Browser/Client| B(Frontend Application);
B -->|GraphQL API Requests| C(Backend API Gateway);
C -->|Auth/Validation| D(Authentication Service);
C --> E(Schema Management Service);
C --> F(Code Generation Service);
C --> G(Integration Service);
E --> H(Persistence Layer - Database);
F --> H;
G --> I(External Data Sources);
D --> H;
subgraph Backend Services
C; D; E; F; G;
end
subgraph Data & Storage
H; I;
end
Explanation:
* Visual Editor Canvas: A component for drag-and-drop type creation and connection.
* Property Panels: Sidebars/modals for editing type and field details.
* SDL Editor: An integrated code editor (e.g., Monaco Editor) with syntax highlighting and auto-completion for GraphQL SDL.
* Schema Viewer/Graph Visualizer: D3.js or similar library for interactive graph visualization.
* Navigation & Project Management: UI for managing projects, schemas, and versions.
* Framework: React, Vue.js, or Angular (e.g., React for its component-based architecture and vast ecosystem).
* State Management: Redux (for React), Vuex (for Vue), NgRx (for Angular).
* GraphQL Client: Apollo Client or Relay for efficient data fetching and caching.
* Styling: Tailwind CSS, Material-UI, or Ant Design.
* Graph Visualization: D3.js, React Flow, or GoJS.
* GraphQL Server: Implements the GraphQL API endpoints.
* API Gateway: (Can be integrated into the GraphQL server or as a separate service for larger scale) Handles request routing, authentication checks, and rate limiting.
* Language: Node.js (TypeScript preferred for type safety), Python, Go, or Java.
* GraphQL Server Framework: Apollo Server (Node.js), Graphene (Python), gqlgen (Go), Spring for GraphQL (Java).
* Web Framework: Express.js (Node.js), FastAPI (Python), Gin (Go), Spring Boot (Java).
* Schema Parser/Validator: Uses a GraphQL parser library (e.g., graphql-js) to parse SDL into an Abstract Syntax Tree (AST) and validate it against the GraphQL specification.
* Internal Schema Representation: A standardized data structure (e.g., JSON schema, internal AST) to represent the GraphQL schema components.
* Schema Versioning Logic: Manages different versions of a schema, allowing for history tracking and reverts.
* Business Logic Controllers: Orchestrate interactions between the database, parser, and other services.
* Language: Same as Backend API Layer (Node.js/TypeScript is suitable given graphql-js).
* Libraries: graphql-js for parsing and validation.
* Users: id, username, email, password_hash, created_at, updated_at.
* Projects: id, name, owner_id (FK to Users), created_at, updated_at.
* Schemas: id, project_id (FK to Projects), name, current_version_id (FK to SchemaVersions), created_at, updated_at.
* SchemaVersions: id, schema_id (FK to Schemas), sdl_content (TEXT), visual_data (JSONB for visual layout), version_number, created_at, created_by (FK to Users).
* Database: PostgreSQL (recommended for its robust JSONB support, transactional integrity, and extensibility) or MongoDB (for flexible document storage).
* ORM/ODM: Prisma, TypeORM, Sequelize (for SQL) or Mongoose (for MongoDB).
* SDL Generator: Converts the internal schema model back into valid GraphQL SDL.
* Resolver Stub Generator: Generates boilerplate code for resolvers in different programming languages.
* Client-side Type Generator (Future): Generates TypeScript interfaces or other client-side types based on the schema.
* Language: Same as Backend API Layer.
* Libraries: Custom templating engines (e.g., Handlebars, EJS) or specialized code generation libraries.
* Database Schema Introspection: Connectors for SQL (PostgreSQL, MySQL), NoSQL (MongoDB), or ORM introspection tools.
* REST API Introspection: Tools to analyze OpenAPI/Swagger definitions and suggest GraphQL types.
* Libraries: Database drivers, OpenAPI parsers.
* User Management: Registration, login, password reset.
* Session/Token Management: JWT (JSON Web Tokens) for stateless authentication.
* Authorization Middleware: Checks user roles and permissions for specific actions (e.g., project ownership, schema editing).
* Libraries: Passport.js (Node.js), Flask-JWT-Extended (Python), Spring Security (Java).
* Stateless Services: Design backend services to be stateless for easy horizontal scaling.
* Database Scaling: Utilize PostgreSQL replication (read replicas) and potentially sharding as data grows.
* Caching: Implement caching (e.g., Redis) for frequently accessed schema metadata or user data.
* CDN: Use a CDN for frontend assets.
* Authentication: Strong password policies, multi-factor authentication (MFA) support (future).
* Authorization: Role-based access control (RBAC) to manage permissions.
* Input Validation: Strict validation on all user inputs to prevent injection attacks.
* Data Encryption: Encrypt sensitive data at rest and in transit (SSL/TLS).
* Rate Limiting: Protect against brute-force and denial-of-service attacks.
* Regular Security Audits: Perform penetration testing and vulnerability scans.
* Monitoring & Logging: Implement comprehensive logging (e.g., ELK stack, Datadog) and monitoring (Prometheus, Grafana) for all services.
* Automated Backups: Regular database backups with point-in-time recovery.
* Redundancy: Deploy services across multiple availability zones.
* Automated Testing: Unit, integration, and end-to-end tests.
* Disaster Recovery Plan: Define procedures for recovering from major outages.
This document outlines a comprehensive GraphQL schema for a Project Management System, encompassing types, queries, mutations, subscriptions, and conceptual resolver implementations. It also includes client-side integration examples to demonstrate interaction with the API.
GraphQL provides a powerful and flexible way to design APIs, allowing clients to request exactly the data they need. This schema is designed for a Project Management System, enabling operations like managing users, projects, tasks, and comments, with real-time updates via subscriptions.
The following sections define the schema using GraphQL's Schema Definition Language (SDL).
These types represent the fundamental data structures within the Project Management System.
# Represents a user in the system.
type User {
id: ID!
name: String!
email: String!
role: UserRole! # e.g., ADMIN, MEMBER, VIEWER
projects: [Project!] # Projects where the user is an owner or member
tasksAssigned: [Task!] # Tasks assigned to this user
}
# Defines the possible roles a user can have.
enum UserRole {
ADMIN
MEMBER
VIEWER
}
# Represents a project.
type Project {
id: ID!
name: String!
description: String
status: ProjectStatus! # e.g., ACTIVE, COMPLETED, ON_HOLD
startDate: String # ISO 8601 date string
endDate: String # ISO 8601 date string
owner: User! # The user who owns the project
members: [User!] # Users who are members of the project
tasks: [Task!] # Tasks belonging to this project
createdAt: String!
updatedAt: String!
}
# Defines the possible statuses for a project.
enum ProjectStatus {
ACTIVE
COMPLETED
ON_HOLD
ARCHIVED
}
# Represents a task within a project.
type Task {
id: ID!
title: String!
description: String
status: TaskStatus! # e.g., TO_DO, IN_PROGRESS, DONE
priority: TaskPriority! # e.g., LOW, MEDIUM, HIGH
dueDate: String # ISO 8601 date string
assignedTo: User # The user assigned to this task
project: Project! # The project this task belongs to
comments: [Comment!] # Comments associated with this task
createdAt: String!
updatedAt: String!
}
# Defines the possible statuses for a task.
enum TaskStatus {
TO_DO
IN_PROGRESS
DONE
BLOCKED
}
# Defines the possible priorities for a task.
enum TaskPriority {
LOW
MEDIUM
HIGH
CRITICAL
}
# Represents a comment on a task.
type Comment {
id: ID!
content: String!
author: User! # The user who wrote the comment
task: Task! # The task this comment belongs to
createdAt: String!
}
Input types are used for mutations to provide structured arguments for creating or updating entities.
# Input for creating a new user or updating an existing one.
input UserInput {
name: String!
email: String!
role: UserRole!
}
# Input for creating a new project or updating an existing one.
input ProjectInput {
name: String!
description: String
status: ProjectStatus
startDate: String
endDate: String
ownerId: ID! # ID of the user who owns the project
memberIds: [ID!] # IDs of users to be members of the project
}
# Input for creating a new task or updating an existing one.
input TaskInput {
title: String!
description: String
status: TaskStatus
priority: TaskPriority
dueDate: String
assignedToId: ID # ID of the user assigned to this task
projectId: ID! # ID of the project this task belongs to
}
# Input for adding a new comment to a task.
input CommentInput {
content: String!
authorId: ID! # ID of the user who authored the comment
taskId: ID! # ID of the task the comment belongs to
}
The Query type defines all read operations available through the API.
type Query {
# --- User Queries ---
# Retrieves a list of all users.
users: [User!]!
# Retrieves a single user by their ID.
user(id: ID!): User
# --- Project Queries ---
# Retrieves a list of all projects, optionally filtered by status or owner.
projects(
status: ProjectStatus
ownerId: ID
): [Project!]!
# Retrieves a single project by its ID.
project(id: ID!): Project
# --- Task Queries ---
# Retrieves a list of tasks, optionally filtered by project, status, assigned user, or priority.
tasks(
projectId: ID
status: TaskStatus
assignedToId: ID
priority: TaskPriority
): [Task!]!
# Retrieves a single task by its ID.
task(id: ID!): Task
# --- Comment Queries ---
# Retrieves comments for a specific task.
comments(taskId: ID!): [Comment!]!
# Retrieves a single comment by its ID.
comment(id: ID!): Comment
}
The Mutation type defines all write operations (create, update, delete) available through the API.
type Mutation {
# --- User Mutations ---
# Creates a new user.
createUser(input: UserInput!): User!
# Updates an existing user.
updateUser(id: ID!, input: UserInput!): User
# Deletes a user. Returns true if successful, false otherwise.
deleteUser(id: ID!): Boolean!
# --- Project Mutations ---
# Creates a new project.
createProject(input: ProjectInput!): Project!
# Updates an existing project.
updateProject(id: ID!, input: ProjectInput!): Project
# Deletes a project. Returns true if successful, false otherwise.
deleteProject(id: ID!): Boolean!
# Adds a member to an existing project.
addProjectMember(projectId: ID!, userId: ID!): Project
# Removes a member from an existing project.
removeProjectMember(projectId: ID!, userId: ID!): Project
# --- Task Mutations ---
# Creates a new task.
createTask(input: TaskInput!): Task!
# Updates an existing task.
updateTask(id: ID!, input: TaskInput!): Task
# Deletes a task. Returns true if successful, false otherwise.
deleteTask(id: ID!): Boolean!
# --- Comment Mutations ---
# Adds a new comment to a task.
addCommentToTask(input: CommentInput!): Comment!
# Deletes a comment. Returns true if successful, false otherwise.
deleteComment(id: ID!): Boolean!
}
The Subscription type defines real-time data streams for events.
type Subscription {
# Notifies when a task within a specific project has been created, updated, or deleted.
# If projectId is not provided, it listens for all task changes.
taskChanged(projectId: ID): TaskChangePayload!
# Notifies when a new comment is added to a specific task.
newCommentAdded(taskId: ID!): Comment!
}
# Payload for task changes, indicating the type of change.
type TaskChangePayload {
mutation: MutationType! # Type of mutation (CREATED, UPDATED, DELETED)
task: Task! # The task that was changed
previousValues: Task # The task's values before the update/delete (optional)
}
# Defines the types of mutations for subscriptions.
enum MutationType {
CREATED
UPDATED
DELETED
}
Combining all the above, here is the complete GraphQL schema:
# --- Enums ---
enum UserRole {
ADMIN
MEMBER
VIEWER
}
enum ProjectStatus {
ACTIVE
COMPLETED
ON_HOLD
ARCHIVED
}
enum TaskStatus {
TO_DO
IN_PROGRESS
DONE
BLOCKED
}
enum TaskPriority {
LOW
MEDIUM
HIGH
CRITICAL
}
enum MutationType {
CREATED
UPDATED
DELETED
}
# --- Core Types ---
type User {
id: ID!
name: String!
email: String!
role: UserRole!
projects: [Project!]
tasksAssigned: [Task!]
}
type Project {
id: ID!
name: String!
description: String
status: ProjectStatus!
startDate: String
endDate: String
owner: User!
members: [User!]
tasks: [Task!]
createdAt: String!
updatedAt: String!
}
type Task {
id: ID!
title: String!
description: String
status: TaskStatus!
priority: TaskPriority!
dueDate: String
assignedTo: User
project: Project!
comments: [Comment!]
createdAt: String!
updatedAt: String!
}
type Comment {
id: ID!
content: String!
author: User!
task: Task!
createdAt: String!
}
type TaskChangePayload {
mutation: MutationType!
task: Task!
previousValues: Task
}
# --- Input Types ---
input UserInput {
name: String!
email: String!
role: UserRole!
}
input ProjectInput {
name: String!
description: String
status: ProjectStatus
startDate: String
endDate: String
ownerId: ID!
memberIds: [ID!]
}
input TaskInput {
title: String!
description: String
status: TaskStatus
priority: TaskPriority
dueDate: String
assignedToId: ID
projectId: ID!
}
input CommentInput {
content: String!
authorId: ID!
taskId: ID!
}
# --- Root Types ---
type Query {
users: [User!]!
user(id: ID!): User
projects(
status: ProjectStatus
ownerId: ID
): [Project!]!
project(id: ID!): Project
tasks(
projectId: ID
status: TaskStatus
assignedToId: ID
priority: TaskPriority
): [Task!]!
task(id: ID!): Task
comments(taskId: ID!): [Comment!]!
comment(id: ID!): Comment
}
type Mutation {
createUser(input: UserInput!): User!
updateUser(id: ID!, input: UserInput!): User
deleteUser(id: ID!): Boolean!
createProject(input: ProjectInput!): Project!
updateProject(id: ID!, input: ProjectInput!): Project
deleteProject(id: ID!): Boolean!
addProjectMember(projectId: ID!, userId: ID!): Project
removeProjectMember(projectId: ID!, userId: ID!): Project
createTask(input: TaskInput!): Task!
updateTask(id: ID!, input: TaskInput!): Task
deleteTask(id: ID!): Boolean!
addCommentToTask(input: CommentInput!): Comment!
deleteComment(id: ID!): Boolean!
}
type Subscription {
taskChanged(projectId: ID): TaskChangePayload!
newCommentAdded(taskId: ID!): Comment!
}
Resolvers are functions that tell the GraphQL server how to fetch the data for a specific field
Project: GraphQL Schema Designer
Step: review_and_document
Date: October 26, 2023
This document provides a comprehensive and detailed GraphQL schema design, complete with type definitions, queries, mutations, subscriptions, conceptual resolver implementations, and integration examples. This design aims to be robust, scalable, and easy to consume for client applications, based on best practices for building a modern API.
This deliverable outlines a foundational GraphQL schema for a typical e-commerce platform, demonstrating how to structure a complete and production-ready API. The schema is designed to be intuitive, performant, and extensible, covering common data models and operations such as user management, product catalog, order processing, and real-time updates.
We will cover:
Before diving into the schema, let's briefly review the fundamental concepts that underpin this design:
* Object Types: Represent the kinds of objects you can fetch from your service, with specific fields (e.g., User, Product, Order).
* Scalar Types: Primitive data types (e.g., String, Int, Float, Boolean, ID). Custom scalars can be defined (e.g., DateTime, JSON).
* Input Types: Special object types used as arguments for mutations, allowing complex data structures to be passed efficiently.
* Enum Types: Represent a set of specific, allowed values (e.g., OrderStatus, ProductCategory).
* Interface Types: Define a set of fields that multiple object types must include, enabling polymorphism.
Our design follows these principles:
User, Product, Order) to improve clarity and maintainability.This section defines the complete GraphQL schema using Schema Definition Language (SDL).
# --- Scalar Types ---
scalar DateTime
scalar JSON # For dynamic key-value pairs or complex data
# --- Enum Types ---
enum UserRole {
CUSTOMER
ADMIN
EDITOR
MODERATOR
}
enum OrderStatus {
PENDING
PROCESSING
SHIPPED
DELIVERED
CANCELLED
RETURNED
}
enum PaymentStatus {
UNPAID
PAID
REFUNDED
FAILED
}
enum ProductCategory {
ELECTRONICS
CLOTHING
BOOKS
HOME_GOODS
FOOD
BEAUTY
SPORTS
OTHER
}
# --- Object Types ---
type User {
id: ID!
email: String!
firstName: String
lastName: String
fullName: String
role: UserRole!
addresses: [Address!]
orders(
first: Int = 10
after: String
status: OrderStatus
): OrderConnection!
createdAt: DateTime!
updatedAt: DateTime!
}
type Address {
id: ID!
street: String!
city: String!
state: String!
zipCode: String!
country: String!
}
type Product {
id: ID!
name: String!
description: String
price: Float!
category: ProductCategory!
imageUrl: String
stock: Int!
reviews(
first: Int = 5
after: String
): ReviewConnection!
createdAt: DateTime!
updatedAt: DateTime!
}
type Review {
id: ID!
product: Product!
user: User!
rating: Int! # 1-5
comment: String
createdAt: DateTime!
updatedAt: DateTime!
}
type Order {
id: ID!
user: User!
items: [OrderItem!]!
totalAmount: Float!
status: OrderStatus!
paymentStatus: PaymentStatus!
shippingAddress: Address!
billingAddress: Address
createdAt: DateTime!
updatedAt: DateTime!
}
type OrderItem {
id: ID!
product: Product!
quantity: Int!
priceAtOrder: Float! # Price when the order was placed
}
# --- Connection Types for Pagination (Relay-style) ---
type UserConnection {
edges: [UserEdge!]!
pageInfo: PageInfo!
}
type UserEdge {
node: User!
cursor: String!
}
type ProductConnection {
edges: [ProductEdge!]!
pageInfo: PageInfo!
}
type ProductEdge {
node: Product!
cursor: String!
}
type OrderConnection {
edges: [OrderEdge!]!
pageInfo: PageInfo!
}
type OrderEdge {
node: Order!
cursor: String!
}
type ReviewConnection {
edges: [ReviewEdge!]!
pageInfo: PageInfo!
}
type ReviewEdge {
node: Review!
cursor: String!
}
type PageInfo {
hasNextPage: Boolean!
hasPreviousPage: Boolean!
startCursor: String
endCursor: String
}
# --- Input Types for Mutations ---
input CreateUserInput {
email: String!
firstName: String
lastName: String
password: String! # In a real app, hash this server-side
role: UserRole = CUSTOMER
}
input UpdateUserInput {
firstName: String
lastName: String
role: UserRole
addresses: [AddressInput!] # Allows updating or adding addresses
}
input AddressInput {
id: ID
street: String!
city: String!
state: String!
zipCode: String!
country: String!
}
input CreateProductInput {
name: String!
description: String
price: Float!
category: ProductCategory!
imageUrl: String
stock: Int!
}
input UpdateProductInput {
name: String
description: String
price: Float
category: ProductCategory
imageUrl: String
stock: Int
}
input CreateReviewInput {
productId: ID!
rating: Int!
comment: String
}
input CreateOrderInput {
items: [OrderItemInput!]!
shippingAddress: AddressInput!
billingAddress: AddressInput
}
input OrderItemInput {
productId: ID!
quantity: Int!
}
input UpdateOrderStatusInput {
orderId: ID!
status: OrderStatus!
}
# --- Root Query Type ---
type Query {
# User Queries
user(id: ID!): User
users(
first: Int = 10
after: String
role: UserRole
search: String
): UserConnection!
# Product Queries
product(id: ID!): Product
products(
first: Int = 10
after: String
category: ProductCategory
minPrice: Float
maxPrice: Float
search: String
sortBy: String = "createdAt" # e.g., "name", "price", "createdAt"
sortOrder: String = "DESC" # "ASC" or "DESC"
): ProductConnection!
# Order Queries
order(id: ID!): Order
orders(
first: Int = 10
after: String
userId: ID
status: OrderStatus
): OrderConnection!
# Review Queries
review(id: ID!): Review
reviews(
first: Int = 10
after: String
productId: ID
userId: ID
): ReviewConnection!
}
# --- Root Mutation Type ---
type Mutation {
# User Mutations
createUser(input: CreateUserInput!): User!
updateUser(id: ID!, input: UpdateUserInput!): User!
deleteUser(id: ID!): Boolean!
# Product Mutations
createProduct(input: CreateProductInput!): Product!
updateProduct(id: ID!, input: UpdateProductInput!): Product!
deleteProduct(id: ID!): Boolean!
# Order Mutations
createOrder(input: CreateOrderInput!): Order!
updateOrderStatus(input: UpdateOrderStatusInput!): Order!
cancelOrder(id: ID!): Order! # Sets status to CANCELLED
# Review Mutations
createReview(input: CreateReviewInput!): Review!
updateReview(id: ID!, rating: Int, comment: String): Review!
deleteReview(id: ID!): Boolean!
}
# --- Root Subscription Type ---
type Subscription {
newProduct: Product!
productUpdated(id: ID!): Product!
newReview(productId: ID): Review! # Optionally filter by product
orderStatusUpdated(userId: ID): Order! # Notify user when their order status changes
newOrder: Order! # For admin to monitor new orders
}
Resolvers are the core logic that fetches data for each field in your schema. They bridge your GraphQL API to your backend data sources (databases, microservices, REST APIs, etc.).
Here's pseudocode demonstrating how some key resolvers would function:
// Example Data Service (e.g., interacting with a database or ORM)
const userService = {
findById: async (id) => { /* fetch user from DB by id */ return { id, email: 'test@example.com', /* ... */ }; },
findAll: async ({ first, after, role, search }) => { /* fetch users with pagination/filtering */ return { edges: [], pageInfo: {} }; },
create: async (input) => { /* create user in DB */ return { id: 'new-id', ...input }; },
update: async (id, input) => { /* update user in DB */ return { id, ...input }; },
delete: async (id) => { /* delete user from DB */ return true; },
};
const productService = {
findById: async (id) => { /* fetch product from DB by id */ return { id, name: 'Sample Product', price: 99.99, /* ... */ }; },
findAll: async ({ first, after, category, search, sortBy, sortOrder }) => { /* fetch products with pagination/filtering */ return { edges: [], pageInfo: {} }; },
create: async (input) => { /* create product in DB */ return { id: 'new-prod-id', ...input }; },
update: async (id, input) => { /* update product in DB */ return { id, ...input }; },
delete: async (id) => { /* delete product from DB */ return true; },
};
const orderService = {
findById: async (id) => { /* fetch order from DB by id */ return { id, status: 'PENDING', /* ... */ }; },
findAll: async ({ first, after, userId, status }) => { /* fetch orders with pagination/filtering */ return { edges: [], pageInfo: {} }; },
create: async (input, userId) => { /* create order in DB for user */ return { id: 'new-order-id', userId, ...input }; },
updateStatus: async (orderId, status) => { /* update order status in DB */ return { id: orderId, status }; },
cancel: async (id) => { /* update order status to CANCELLED */ return { id, status: 'CANCELLED' }; },
};
const reviewService = {
findById: async (id) => { /* fetch review from DB by id */ return { id, rating: 5, comment: 'Great!', /* ... */ }; },
findAll: async ({ first, after, productId, userId }) => { /* fetch reviews with pagination/filtering */ return { edges: [], pageInfo: {} }; },
create: async (input, userId) => { /* create review in DB for user and product */ return { id: 'new-review-id', userId, ...input }; },
update: async (id, input) => { /* update review in DB */ return { id, ...input }; },
delete: async (id) => { /* delete review from DB */ return true; },
};
// PubSub mechanism for Subscriptions (e.g., using 'graphql-subscriptions' or Redis PubSub)
const pubsub = {
publish: (eventName, payload) => { /* Send event to subscribers */ },
asyncIterator: (eventName) => { /* Return an async iterator for event */ },
};
// Root Resolver Map
const resolvers = {
DateTime: new GraphQLScalarType({ /* ... custom scalar implementation ... */ }),
JSON: new GraphQLScalarType({ /* ... custom scalar implementation ... */ }),
Query: {
// User Resolvers
user: async (parent, { id }, context) => userService.findById(id),
users: async (parent, args, context) => userService.findAll(args),
// Product Resolvers
product: async (parent, { id }, context) => productService.findById(id),
products: async (parent, args, context) => productService.findAll(args),
// Order Resolvers
order: async (parent, { id }, context) => orderService.findById(id),
orders: async (parent, args, context) => {
// In a real app, context.user.id would be used for authorization
if (!context.user.isAdmin && args.userId && args.userId !== context.user.id) {
throw new Error("Unauthorized to view other users' orders.");
}
return orderService.findAll(args