Apollo GraphOS

Apollo authored the Federation v2 specification, which lets multiple independently-deployed GraphQL subgraphs be composed into a single supergraph. Teams own their own services and schemas while clients see one unified API. This is the architectural foundation that made Apollo the default choice at Netflix, Walmart, and other large-scale GraphQL adopters.

The Apollo Router is a high-performance, Rust-based gateway that executes federated queries against subgraphs. It replaces the older Node.js gateway and is designed for production throughput at enterprise scale, with support for query planning, caching, rhai scripting, and coprocessors. It can be run self-hosted or as a managed cloud routing service inside GraphOS.

Every subgraph schema is registered with GraphOS, which then composes the supergraph and runs static and traffic-based checks against proposed changes. In CI/CD, schema checks flag breaking changes before they ship by comparing against real client operation history. This prevents the common GraphQL failure mode of silently breaking a field that a mobile app still depends on.

GraphOS captures per-field usage, latency, and error metrics across the entire supergraph, with trace sampling down to subgraph hops. Teams can see which clients use which fields, spot slow resolvers, and make data-driven deprecation decisions. This level of granularity is one of the main reasons large organizations adopt the managed platform over self-hosted alternatives.

Apollo explicitly positions GraphOS as an orchestration layer for AI agents, where the GraphQL schema acts as a typed, introspectable tool catalog for LLMs. Combined with persisted queries and RBAC, agents can be restricted to a safelist of operations, reducing the risk of hallucinated or unsafe API calls. This is a relatively new angle for Apollo but central to its 2025-2026 positioning.