New in Apollo Router v1.12: Improved router security, performance, and extensibility

Just over a year ago, we introduced Apollo Router, the graph router that is now at the heart of Apollo GraphOS. Unlike its predecessor Apollo Gateway, Apollo Router was designed to maximize the performance benefits of GraphQL and supergraph architecture, while being secure by default. After switching to the router, one customer reported a 93% reduction in gateway cloud spend, a 30x reduction in Kubernetes Pod counts, and 70% less code to maintain – while delivering even faster response times, with a 70% reduction in request latencies! 

Today, some of the world’s largest companies rely on GraphOS for their mission-critical graph API infrastructure. Routers have processed 100% of Black Friday traffic for top-100 retail companies, and major fintech organizations are trusting their routers to handle tax season.

So what’s next?

Many of Apollo Router’s initial users are running billions of operations each month with GraphOS. The features in this release focus on the challenges of operating a graph router at massive scale: defense in depth, maximizing performance, and extensibility. Today, we are excited to make three new features generally available to GraphOS Enterprise customers running a self-hosted router: JWT auth, distributed APQ caching, and support for external coprocessors.

Supergraph defense-in-depth

Block malicious traffic at the edge of your graph with new JWT auth support in the router.

Previously, the router could only forward user access tokens (JWT) generated by identity providers like Auth0 or Okta onto subgraphs and underlying REST APIs. Keeping your supergraph secure meant doing JWT checks in every subgraph or REST API which allows attackers deeper into your graph – and missing a single check often results in security holes.

Now, with the router as a security-hardened entry point to your graph, you can reject malicious traffic early and shield your subgraphs and REST APIs from unwanted traffic. Router v1.12 adds support for JWT validation, claim extraction, and custom security policies in Rhai scripting to reject bad traffic at the edge of the graph – for enhanced zero-trust and defense-in-depth. Extracting claims once in the router and securely forwarding them to subgraphs has several key benefits, including:

• Reducing operational burden on backend API teams – no JWT keys to manage
• Reducing latency due to JWT processing – since the JWT is processed only once in the router
• Speeding up response times – by selectively forwarding JWT claims for increased query deduplication

These performance benefits compound at scale, particularly if the router is simultaneously processing similar queries.

Maximize performance at scale

Reduce p99 latency during peak traffic with Distributed APQ (automatic persisted query) caching with Redis.

APQ can drastically reduce response latency by allowing clients to send only a unique hash over the wire instead of a large query document, providing a fast path to query execution. You may already have in-memory APQ configured for your router, however when load balancing requests over a large fleet of router instances, the in-memory cache won’t be consistently hot. Unlucky users, especially during scaling events, will hit cold caches and experience slower response times as the APQ cache must be built individually in each router instance.

With Router v1.12 , you can now use distributed APQ caching to improve p99 latencies during peak times. A shared Redis instance can now be used by the entire router fleet to build the APQ cache faster and share existing APQ cache with new router instances that are spun up during scaling events – when they need it most. This ensures the fast path to query execution is consistently available to all users even during peak load.

Extensibility with coprocessors

Extend the router in your language of choice using new external coprocessor support.

To create common customizations for Apollo Gateway like header propagation and error handling, you have to code plugins and middleware directly into a custom gateway package. These monolithic gateway packages must be built and deployed as a single unit, often requiring coordination across teams. Since everything is run in a single process, errors in the custom code can crash the whole Gateway, and it’s not clear which team should be paged at 3 am to resolve the issue.

With Apollo Router, most common customizations are built directly into the stock binary and can be configured with YAML. YAML config alone allowed one of our largest Enterprise customers to eliminate 70% of their custom Gateway code.

In cases where the YAML config isn’t enough, Router also supports Rhai scripting (similar to Lua in NGINX and Envoy) which can be used for in-memory manipulation of headers, cookies, and more with a well-defined Rhai API reference. Rhai scripts are great for lightweight customizations and provide a safe, sandboxed way to customize the Router’s request flow.

For more powerful customizations, the Router now supports external coprocessors written in the programming language of your choice. Coprocessors run with full isolation and a clean separation of concerns, that decouples delivery and provides fault isolation. Low overhead can be achieved by running coprocessors alongside the router on the same host or in the same Kubernetes Pod as a sidecar. Coprocessors can be used to speed Gateway migrations, support bespoke use cases, or integrate the router with existing network services for custom auth (JWT mapping, claim enrichment), service discovery integration, and more!

However, our goal is to eliminate as much custom code as possible, so if you have a common use case that you think should be supported in the stock Apollo Router binary, be sure to open an issue.

Enabling GraphOS Enterprise features

Upgrade to Router v1.12 and ensure they are connected to GraphOS with an Enterprise plan.

All Apollo GraphOS Enterprise customers can access these features today for self-hosted instances of Apollo Router. If your router is already connected to GraphOS Studio using your APOLLO_KEY and APOLLO_GRAPH_REF, and you’re running the latest version of Apollo Router, no further action is required! You can set up all of these features in your existing router config. See the documentation for additional details.

These are just the first of many router features on the roadmap for GraphOS. We have exciting security and performance features coming up soon for GraphOS Enterprise as well as GraphOS Cloud, so stay tuned!

Optimize Apollo Router with tips from the Apollo community

The Apollo Router is a core part of the Apollo stack, and we want you to feel confident to trust it with your queries in production. The Apollo Champions community features many customers who have already made this switch and have insights that can help, including the team at Wayfair. They switched to Apollo Router from Gateway before Black Friday. The Wayfair team will discuss how they made the switch as well as the improvements they saw as a result. Be sure to tune in to the Apollo Champion’s Corner on March 23rd to learn more.