Skip to content

GraphQL Federation: Apollo Router vs Hasura

CoreConceptAugust 5, 20264 min read

Building a single monolithic GraphQL server across dozens of engineering teams creates code ownership conflicts and deployment bottlenecks. A single unhandled exception in one resolver can crash the entire API schema, while merging schema definitions requires coordination across multiple domain teams.

GraphQL Federation solves schema fragmentation by composing independent domain subgraph schemas into a single unified Supergraph Schema. Apollo Router (written in high-performance Rust) parses client GraphQL queries, generates an optimized query execution plan, and fetches entity fields from downstream subgraph services in parallel. Hasura offers instant auto-generated GraphQL APIs directly over relational databases. This guide compares Apollo Federation v2 directives (@key, @shareable), query planner algorithms, Hasura database engine compilation, and N+1 query prevention.

GraphQL Federation architecture comparison featuring Apollo Router Rust supergraph query planning, Apollo Federation v2 directives, and Hasura instant SQL compilation
GraphQL Federation architecture comparison featuring Apollo Router Rust supergraph query planning, Apollo Federation v2 directives, and Hasura instant SQL compilation

Mental Model: Monolithic GraphQL Schemas vs Federated Supergraph Gateways

Monolithic GraphQL servers consolidate all resolvers into a single application codebase. Federated GraphQL architecture separates schema ownership across microservices:

1. Subgraph Microservices: Accounts Service, Products Service, and Reviews Service each own and deploy their local GraphQL subgraphs independently. 2. Apollo Router Supergraph Gateway: Fetches subgraph schemas, composes a unified Supergraph Schema file via rover supergraph compose, and routes incoming GraphQL queries dynamically. For API gateways and microservice security, review securing api gateways oauth2 m2m client credentials and high performance api gateway.

Apollo Router supergraph query execution flow showing query planning, parallel subgraph entity requests, and JSON response assembly
Apollo Router supergraph query execution flow showing query planning, parallel subgraph entity requests, and JSON response assembly

Quick reference

  • Enables autonomous domain teams to own, develop, and deploy GraphQL subgraphs independently.
  • Apollo Router composes subgraphs into a single unified Supergraph Endpoint at edge.
  • Rust-based Apollo Router processes query planning and entity fetching in under 1 millisecond.
  • Prevents single-point-of-failure schema crashes across enterprise microservice teams.
  • Powers federated GraphQL graphs at Netflix, PayPal, Wayfair, Expedia, and CoreConcept.

Remember this

Adopt Apollo Federation v2 to compose autonomous domain subgraphs into a unified supergraph.

Apollo Federation v2 Declarative Directives (@key, @shareable, @override)

Apollo Federation v2 relies on declarative schema directives to link entity types across subgraphs:

1# Accounts Subgraph2type User @key(fields: "id") {3  id: ID!4  email: String!5}6 7# Reviews Subgraph (Extends User Entity)8type User @key(fields: "id", resolvable: true) {9  id: ID!10  reviews: [Review!]!11}12 13# Products Subgraph (@shareable allows multiple subgraphs to resolve identical fields)14type Product @key(fields: "sku") {15  sku: ID!16  name: String! @shareable17  price: Float! @override(from: "LegacyCatalog")18}

Quick reference

  • @key directive defines primary entity keys (id, sku) for cross-subgraph entity resolution.
  • _entities query resolver fetches entity fields across subgraph boundaries dynamically.
  • @shareable allows multiple subgraphs to resolve identical fields without conflict.
  • @override transfers field ownership from legacy subgraphs to new microservices seamlessly.
  • Eliminates tight coupling and code duplication across distributed GraphQL schemas.

Remember this

Use @key and @shareable directives to compose entity fields across independent subgraphs.

Apollo Router (Rust) vs Hasura Engine Query Execution Mechanics

Evaluating Apollo Router vs Hasura highlights distinct architectural trade-offs:

- Apollo Router: High-throughput Rust query planner that executes multi-step async DAG plans. It proxies entity requests to custom Node.js, Go, or Java subgraphs via HTTP/gRPC. - Hasura Data Engine: Auto-generates GraphQL APIs by compiling incoming GraphQL AST queries directly into single optimized SQL statements (SELECT json_agg(...)) over PostgreSQL, MySQL, or MS SQL Server.

Apollo Router supergraph query execution flow showing query planning, parallel subgraph entity requests, and JSON response assembly
Apollo Router supergraph query execution flow showing query planning, parallel subgraph entity requests, and JSON response assembly

Quick reference

  • Apollo Router Rust core delivers 10x higher throughput than legacy Node.js Apollo Gateway.
  • Hasura compiles GraphQL queries into single SQL statements, bypassing object-relational mapping.
  • Apollo Router provides total flexibility for custom microservice business logic.
  • Hasura excels at instant CRUD API generation over existing relational database tables.
  • Delivers sub-millisecond query execution for high-concurrency production workloads.

Remember this

Choose Apollo Router for custom microservice subgraphs and Hasura for instant database GraphQL APIs.

Mitigating N+1 Query Traps, Entity Caching, & Security Rate Limits

GraphQL flexibility introduces performance risks if query execution is left unmonitored:

1. N+1 Query Traps: Dataloader batching (in subgraphs) consolidates $N$ individual database queries into a single SELECT * FROM items WHERE id IN (...) batch query. 2. Query Depth & Complexity Limits: Apollo Router enforces maximum query depth (e.g. max 5 nested selection sets) and query cost calculation to block malicious nested queries.

Quick reference

  • Dataloader batching in subgraphs eliminates N+1 SQL queries during nested array resolution.
  • Apollo Router response caching caches sub-tree entity results in Redis or memory.
  • Query depth and complexity limits prevent Denial of Service (DoS) from deeply nested queries.
  • Persisted Queries (APQ) reduce network request sizes by sending SHA-256 query hashes.
  • Protects downstream databases and microservice subgraphs from traffic spikes.

Remember this

Implement Dataloader batching and query depth limits to protect subgraphs from N+1 query traps.

Key takeaway

To test Apollo Federation v2 locally, install rover via curl -sSL https://rover.apollo.dev/nix/latest | sh and run rover supergraph compose --config ./supergraph.yaml.

Share:

Related Articles

Selecting the communication protocol between clients, API gateways, and internal microservices impacts API latency, payl

Read

Five Docker containers with REST between them is not a production microservices system. Clients hit a load balancer and

Read

A checkout call may hit REST at the gateway, a GraphQL BFF for the mobile screen, gRPC between order and inventory, and

Read

Keep learning

Follow a structured path or browse all courses to go deeper.