Graphql Expert
apollo caching
When reviewing or writing code, apply these guidelines:
- Utilize Apollo Client's caching capabilities
apollo custom hooks
When reviewing or writing code, apply these guidelines:
- Implement custom hooks for Apollo operations
apollo devtools
When reviewing or writing code, apply these guidelines:
- Use Apollo Client DevTools for debugging
apollo provider setup
When reviewing or writing code, apply these guidelines:
- Use Apollo Provider at the root of your app
graphql apollo client usage
When reviewing or writing code, apply these guidelines:
- Use Apollo Client for state management and data fetching
- Implement query components for data fetching
- Utilize mutations for data modifications
- Use fragments for reusable query parts
- Implement proper error handling and loading states
graphql error boundaries
When reviewing or writing code, apply these guidelines:
- Implement proper error boundaries for GraphQL errors
graphql naming conventions
When reviewing or writing code, apply these guidelines:
- Follow naming conventions for queries, mutations, and fragments
graphql typescript integration
When reviewing or writing code, apply these guidelines:
- Use TypeScript for type safety with GraphQL operations
Iron Laws
- ALWAYS implement query depth and complexity limits in production GraphQL servers — unbounded queries allow clients to construct exponentially expensive nested queries that exhaust server resources (DoS via query complexity).
- NEVER expose introspection in production environments — introspection reveals the full schema, type relationships, and field names, providing attackers with a detailed map for targeted queries.
- ALWAYS use DataLoader (or equivalent batching) for any resolver that fetches related entities — without batching, every list item triggers a separate DB query (N+1 problem), causing catastrophic performance degradation.
- NEVER perform authorization checks at the schema level only — always enforce authorization inside resolvers; field-level auth in schema directives can be bypassed via aliased queries or introspection.
- ALWAYS use cursor-based pagination for list queries — offset-based pagination becomes inconsistent when items are inserted/deleted between pages and degrades to O(n) DB scans at high offsets.
Anti-Patterns
| Anti-Pattern | Why It Fails | Correct Approach |
|---|---|---|
| No query depth/complexity limits | Single deeply-nested query can DoS the server | Configure graphql-depth-limit and graphql-query-complexity middleware |
| Introspection enabled in production | Exposes full schema to attackers; aids targeted exploitation | Disable via introspection: false in Apollo Server config for production |
| N+1 resolver queries | Each list item triggers separate DB query; 100 users = 100 queries | Use DataLoader to batch and deduplicate DB fetches per request |
| Authorization only in schema directives | Directives can be bypassed by aliasing fields or crafting custom queries | Check permissions inside every resolver; use context for user/role |
| Offset-based pagination | Inconsistent pages when data changes; O(n) scan at large offsets | Use cursor-based pagination with first, after, and opaque cursor tokens |
Consolidated Skills
This expert skill consolidates 1 individual skills:
- graphql-expert
Memory Protocol (MANDATORY)
Before starting:
cat .claude/context/memory/learnings.mdAfter completing: Record any new patterns or exceptions discovered.
ASSUME INTERRUPTION: Your context may reset. If it's not in memory, it didn't happen.