API Gateway vs GraphQL Federation: Scaling a Microservices API
API Gateway vs GraphQL Federation comparison 2026 — Kong, AWS API Gateway vs Apollo Federation, Cosmo Router — routing, schema composition, auth, rate limiting, and microservices scaling.
Quick Answer
API gateways (Kong, AWS API Gateway, Traefik) are protocol-agnostic — they route REST, gRPC, and WebSocket traffic with auth, rate limiting, and observability at the edge. GraphQL Federation (Apollo, Cosmo) composes multiple GraphQL subgraphs into one unified schema. Use a gateway for general microservices routing; use federation to unify a GraphQL-first architecture.
API Gateway vs GraphQL Federation: Overview
REST microservices, mixed-protocol routing, enterprise edge security, multi-team API surface
Kong OSS (free); AWS API Gateway (1M calls/month free tier); Traefik OSS (free)
Kong Enterprise from $750/month; AWS API Gateway $3.50/million calls; Traefik Enterprise custom
GraphQL-first architectures, multi-team schema ownership, BFF aggregation layers
Apollo Router (free OSS); Apollo Studio free tier; WunderGraph Cosmo free plan
Apollo GraphOS from $0 (free) to enterprise; Cosmo from $299/month
API Gateway vs GraphQL Federation: Feature Comparison
| Feature | API Gateway | GraphQL Federation |
|---|---|---|
| Protocol Support | REST, gRPC, WebSocket, GraphQLWinner | GraphQL only |
| Schema Composition | None (path-based routing) | Full (@key, @external, @requires)Winner |
| Auth / Rate Limiting | Native (JWT, OAuth, per-route limits)Winner | Router plugins (less mature) |
| Cross-Service Data Join | Requires BFF aggregation layer | Built-in entity resolutionWinner |
| Team Schema Ownership | Per-service route ownership | Per-subgraph schema ownershipWinner |
| Open-Source Option | Kong OSS, Traefik | Apollo Router, Cosmo |
Pros & Cons
API Gateway
Pros
- Protocol-agnostic: routes REST, gRPC, WebSocket, and GraphQL — single entry point for all traffic types
- Edge security: JWT validation, OAuth 2.0, API key management, mTLS, and WAF plugins at the gateway layer
- Rate limiting + quotas: per-consumer, per-tier, and per-endpoint rate limits without touching service code
- Observability: request tracing (Jaeger/Zipkin), metrics (Prometheus), and access logging built into Kong and AWS AG
- No service code changes: route new services by updating gateway config — services remain decoupled from routing logic
Cons
- No schema composition: multiple REST endpoints appear as separate paths — no unified type system across services
- Aggregation complexity: joining data from multiple services requires a separate aggregation service or BFF layer
- GraphQL-unaware: cannot enforce GraphQL query depth limits, field-level auth, or operation-level rate limits without plugins
- Config sprawl: large deployments accumulate hundreds of route/plugin configurations that are hard to audit
GraphQL Federation
Pros
- Unified schema: compose 10+ subgraph services into one type-safe supergraph — @key directive stitches entities across services
- Team autonomy: each team owns their subgraph schema independently — Apollo Studio schema checks catch breaking changes in CI
- Query planning: Apollo Router distributes query fragments to relevant subgraphs, merges results — one client request = N internal calls
- Entity resolution: @external/@requires/@provides directives enable cross-service joins without a BFF service
- Cosmo alternative: WunderGraph Cosmo is a fully open-source federation router — no Apollo pricing for high-traffic deployments
Cons
- GraphQL-only: federation only works for GraphQL subgraphs — REST, gRPC, or WebSocket services must be wrapped in a GraphQL adapter
- Complex debugging: distributed query plans across subgraphs are harder to trace than single-service GraphQL or REST
- Apollo pricing at scale: Apollo GraphOS enterprise pricing can reach $50K+/year for high-schema-operation volume
- N+1 across subgraphs: entity resolution loops can trigger unexpected fan-out — requires careful @key and @requires design
Our Verdict: API Gateway vs GraphQL Federation
Use an API gateway (Kong, Traefik, AWS API Gateway) when your microservices use mixed protocols, when you need edge-level auth/rate limiting/WAF for a public API, or when your teams are not committed to GraphQL across all services. Use GraphQL Federation (Apollo Router or Cosmo) when your architecture is GraphQL-first, you have multiple teams owning different parts of the schema, and you want to eliminate the BFF aggregation layer by using entity resolution. For most enterprises in 2026, the answer is both: an API gateway at the edge for security and protocol routing, and GraphQL Federation as the query layer for client-facing data aggregation sitting behind the gateway.
API Gateway vs GraphQL Federation — FAQs
What is the difference between Apollo Federation and Apollo Gateway, and which should I use in 2026?
Apollo Gateway (the JavaScript-based gateway from 2018) is the legacy federation runtime and is deprecated in favour of Apollo Router (Rust-based, released 2022). Apollo Router is significantly faster — it processes 8–10x more requests per second than the JavaScript gateway at lower memory — and is the only supported path for Apollo Federation 2 features including @interfaceObject and progressive @override. In 2026, all new federation deployments should use Apollo Router. WunderGraph Cosmo is the open-source alternative that is fully federation-spec compatible and does not require an Apollo Studio account — it is the recommended choice for teams that want to self-host the router without Apollo commercial licensing.
Can I use GraphQL Federation alongside a non-GraphQL API gateway?
Yes — this is the standard production pattern. A public-facing API gateway (Kong or AWS API Gateway) sits at the edge, handling TLS termination, API key authentication, DDoS protection, and rate limiting. GraphQL Federation (Apollo Router or Cosmo) sits behind the gateway as an internal service, receiving only authenticated, rate-limited GraphQL traffic. The gateway treats the Apollo Router as a single upstream — it does not need to understand GraphQL semantics. This gives you edge security without modifying the federation router, and federation schema composition without adding those concerns to the gateway. Most enterprise GraphQL deployments in 2026 use this layered architecture.
How does GraphQL Federation handle authentication and authorization across subgraphs?
Authentication is typically handled at the gateway or router layer before requests reach subgraphs — Kong or AWS API Gateway validates JWTs and passes claims as headers to Apollo Router. Authorization is more nuanced: field-level auth (can user X query field Y on type Z) must be implemented in each subgraph resolver using the forwarded claims. Apollo Router supports operation-level auth checks via coprocessors (custom HTTP webhooks) and the native JWT plugin (Enterprise). Authorization directives (@authenticated, @requiresScopes) are supported in Apollo Federation 2.5+ and Cosmo, enabling schema-level permission declarations that the router enforces before dispatching to subgraphs. This is the recommended approach over scattered resolver-level checks in 2026.
Try the Best AI Platform — Free
Assisters brings the best of AI together in one platform. No credit card required to start.