graphql-performance-optimizer

# fetches the source and writes it to:
.claude/agents/graphql-performance-optimizer.md

What it is

GraphQL performance analysis and optimization specialist. Use PROACTIVELY for query performance issues, N+1 problems, caching strategies, and production GraphQL API optimization. Specifically:\n\n\nContext: An existing resolver file is causing visible slowdowns when loading lists of users with their related orders.\nuser: "Our user list page takes 3–4 seconds to load. Each user has related orders fetched in a separate resolver. Can you diagnose and fix it?"\nassistant: "I'll scan the resolver file for N+1 patterns, instrument DataLoader batching for the orders relation, and verify the fix with a before/after query count."\n\nUse this agent when N+1 is suspected in a specific resolver file. It reads existing code, identifies per-record database calls, and rewrites affected resolvers to use request-scoped DataLoader instances — without touching the schema.\n\n\n\n\nContext: A high-traffic public API needs to reduce origin load and improve cache-ability without changing the client query surface.\nuser: "We serve 50k requests/minute. Can you implement APQ + CDN caching to cut origin hits?"\nassistant: "I'll enable Automatic Persisted Queries on the Apollo Server, configure a Redis APQ store, add cache-control directives at the field level, and set up the CDN to cache GET-based persisted query responses."\n\nInvoke this agent when the primary goal is reducing origin load for a public or semi-public API where the client is controlled but Trusted Documents are not feasible (e.g., third-party mobile apps). APQ converts frequent queries to short GET requests the CDN can cache.\n\n\n\n\nContext: A federated graph with three subgraphs is showing 800ms p95 latency on a product-detail query that spans users, inventory, and pricing subgraphs.\nuser: "Our federated product query is slow in production. Apollo Studio shows the query plan is fine but subgraph response times are high. How do we profile and fix it?"\nassistant: "I'll add router-level query plan caching, ensure each subgraph instantiates DataLoaders per request context, and implement __resolveReference batch loading for the Product entity to collapse the cross-subgraph entity fetches."\n\nUse this agent when latency lives inside federation entity resolution. It targets router query plan caching, subgraph DataLoader scoping, and batch reference resolvers — concerns distinct from single-service optimization.\n\n

When to use it

GraphQL performance analysis and optimization specialist. Use PROACTIVELY for query performance issues, N+1 problems, caching strategies, and production GraphQL API optimization. Specifically:\n\n\nContext: An existing resolver file is causing visible slowdowns when loading lists of users with their related orders.\nuser: "Our user list page takes 3–4 seconds to load. Each user has related orders fetched in a separate resolver. Can you diagnose and fix it?"\nassistant: "I'll scan the resolver file for N+1 patterns, instrument DataLoader batching for the orders relation, and verify the fix with a before/after query count."\n\nUse this agent when N+1 is suspected in a specific resolver file. It reads existing code, identifies per-record database calls, and rewrites affected resolvers to use request-scoped DataLoader instances — without touching the schema.\n\n\n\n\nContext: A high-traffic public API needs to reduce origin load and improve cache-ability without changing the client query surface.\nuser: "We serve 50k requests/minute. Can you implement APQ + CDN caching to cut origin hits?"\nassistant: "I'll enable Automatic Persisted Queries on the Apollo Server, configure a Redis APQ store, add cache-control directives at the field level, and set up the CDN to cache GET-based persisted query responses."\n\nInvoke this agent when the primary goal is reducing origin load for a public or semi-public API where the client is controlled but Trusted Documents are not feasible (e.g., third-party mobile apps). APQ converts frequent queries to short GET requests the CDN can cache.\n\n\n\n\nContext: A federated graph with three subgraphs is showing 800ms p95 latency on a product-detail query that spans users, inventory, and pricing subgraphs.\nuser: "Our federated product query is slow in production. Apollo Studio shows the query plan is fine but subgraph response times are high. How do we profile and fix it?"\nassistant: "I'll add router-level query plan caching, ensure each subgraph instantiates DataLoaders per request context, and implement __resolveReference batch loading for the Product entity to collapse the cross-subgraph entity fetches."\n\nUse this agent when latency lives inside federation entity resolution. It targets router query plan caching, subgraph DataLoader scoping, and batch reference resolvers — concerns distinct from single-service optimization.\n\n

How to install / invoke

# Copy the agent definition into your project's .claude/agents/
curl -sL https://raw.githubusercontent.com/davila7/claude-code-templates/main/cli-tool/components/agents/api-graphql/graphql-performance-optimizer.md -o .claude/agents/graphql-performance-optimizer.md

Notes

Extracted from davila7/claude-code-templates, api-graphql category.