- Home
- Skills
- Williamzujkowski
- Cognitive Toolworks
- Api Graphql Designer
api-graphql-designer_skill
- Python
5
GitHub Stars
2
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill williamzujkowski/cognitive-toolworks --skill api-graphql-designer- CHANGELOG.md1.3 KB
- SKILL.md15.3 KB
Overview
This skill helps you design robust GraphQL schemas for standalone, federated, or stitched architectures. It generates SDL, resolver patterns, and production-ready guidance for pagination, DataLoader usage, and field-level security. Use it to move from domain models or REST endpoints to scalable GraphQL services with n+1 prevention and federation support.
How this skill works
I inspect provided entity definitions, schema_type, and optional federation_config to produce a complete SDL and resolver patterns. The skill applies tiered procedures: a fast T1 path for basic standalone schemas, T2 for production optimizations (DataLoader, cursor pagination, auth directives, federation v2), and T3 for advanced stitching, subscriptions, and monitoring. Outputs include schema_definition, resolver_patterns, optimization_config, and federation_config when required.
When to use it
- Designing a new GraphQL API from domain entities for a single service
- Converting REST endpoints into a unified GraphQL schema
- Implementing Apollo Federation v2 across microservices
- Preventing n+1 queries using DataLoader patterns
- Stitching multiple GraphQL services or integrating third-party schemas
Best practices
- Start with clear entity definitions and mark non-nullable fields based on business rules
- Use per-request DataLoader instances to batch and cache DB access for relationships
- Prefer cursor-based (Relay) pagination for large datasets and offset for simple admin lists
- Add field-level @auth directives and limit query complexity and depth (max 7–10)
- Define @key on federated entities and implement __resolveReference for each subgraph
Example use cases
- Generate a standalone SDL with Query/Mutation roots, input types, and offset pagination
- Produce a federated User subgraph with @key, reference resolvers, and DataLoader-backed relations
- Create a stitched gateway schema that delegates queries to legacy GraphQL services
- Add subscription definitions and PubSub patterns for real-time updates
- Prepare production config: query complexity limits, depth limiting, and caching strategy
FAQ
Provide schema_type (standalone|federated|stitched) and a non-empty entities array; federated schemas also require federation_config.
How does the skill prevent n+1 queries?
It emits resolver patterns using per-request DataLoader instances that batch keys and cache results for the duration of a request.
When should I choose federation over stitching?
Use federation for homogeneous subgraphs and independent team ownership (Apollo ecosystem). Use stitching for mixed or third-party GraphQL integration and legacy services.