apollo-router_skill

Overview

This skill is a version-aware generator and guide for configuring and running Apollo Router for federated GraphQL supergraphs. It produces Router v1.x or v2.x–compatible YAML, guides feature selection, collects parameters, and enforces a post-generation validation checklist. Use it to create secure, runnable router.yaml files tuned for production or development environments.

How this skill works

The skill first asks which Router major version you target and whether the environment is production or development, then loads the matching base template. It walks through optional features (CORS, JWT, telemetry, connectors, limits, APQ, subscriptions, etc.), collects parameter values, injects those values into the correct versioned snippets, and assembles a final YAML with a top comment stating the target version. A required validation gate runs a checklist and recommends running the Router CLI validator when available.

When to use it

• Initial setup of Apollo Router for a new or migrated supergraph
• Adding or updating routing, headers, CORS, JWT auth, or telemetry
• Implementing custom plugins (Rhai scripts or coprocessors) or connectors
• Tuning operation limits, rate limiting, and timeouts for performance
• Troubleshooting Router connectivity, validation errors, or schema issues

Best practices

• Always choose Router v2 for new projects; ask the version before generating config
• Use production template defaults: introspection=false, sandbox=false, homepage disabled
• Never use wildcard CORS in production; list explicit origins and warn on '*'
• Store secrets as environment variables (${env.VAR}) and avoid including APOLLO_KEY in repo or logs
• Start limits with max_depth: 50 and use warn_only: true to observe traffic before enforcing
• Prefer GraphOS-managed runtime for production; use --dev and --hot-reload for local development

Example use cases

• Generate a v2 production router.yaml with JWT auth, CORS, Prometheus metrics, and APQ enabled
• Migrate a legacy v1 router.yaml to v2 using the upgrade path and validate differences
• Add a REST connector for a subgraph (v2 only) with per-source $config injected
• Tune operation depth and rate limits in warn_only mode to collect usage signals before enforcing
• Validate a generated router.yaml against the post-generation checklist and the Router CLI