Introducing the Apollo Router - our Federation runtime in Rust!

We’re excited to unveil our next-generation GraphQL Federation runtime: the Apollo Router. The Apollo Router is written in Rust, and it is fast . :zap: Early benchmarks show that the Router adds less than 10ms of latency to each operation, and it can process 8x the load of the JavaScript Apollo Gateway. Packaged as a standalone, multi-threaded binary, the Router can use all available CPU cores without needing to run multiple instances on a single machine.

Getting Started:

We’d love to hear what you think! :pray:


Looks super cool!

Possibly some silly questions but the docs make it seem like Router is a separate executable that runs by itself.

Is there a plan to have it be a npm package similar to Gateway? Will it eventually integrate into Gateway? Replace it? Or be an alternative?

I’m struggling to grasp how this would be used practically when it seems that it would be pretty common to have gateway-level code and configuration that would be specific to a business such as secret management, authorization, logging, non-managed or custom-managed federation (thinking about the ongoing thread/discussion about replacing serviceList).

Am I completely off my rocker or missing the point here? :slight_smile:

Hi @andrewmcgivery :wave:

Yes, the Apollo Router is a separate binary executable (written in Rust) that is a higher-performance alternative to the Apollo Gateway (written in JavaScript) that performs the same federated graph routing functions:

  • accepts client requests
  • plans and executes those requests across subgraphs
  • returns responses back to the client

The Apollo Gateway is quite fast and horizontally scalable today, but to get a 10x performance improvement we needed to write the Apollo Router in a lower-level systems language like Rust. We’ve aimed to make the Router as backwards compatible as possible, but there will be a new extensibility model – one we hope will be language-neutral as well!

The Apollo Gateway, written in JavaScript, will continue to be supported in both the 0.x Gateway npm package and the new 2.x Gateway npm package with support for Apollo Federation 2 (currently in alpha).

The Apollo Router and Apollo Gateway v2.x share the same query planning engine to ensure consistency across both graph routing implementations (Gateway and Router). This should make migration from the Gateway to the Router transparent to all subgraph teams, since all subgraphs that compose into supergraphs today will continue to work in both the Apollo Gateway and the new Apollo Router.

The Apollo Gateway is written in JavaScript and supports gateway-level code, configuration, and plugins that are centered around the JavaScript ecosystem. This enables integration with custom secret management, authorization, logging, and so forth – which are typically handled by the graph platform developers that own building and deploying the Gateway itself.

The Apollo Router, written in Rust, will also offer a well-defined extensibility model, but also more natively supported features to reduce the amount of custom code where possible. We’re aiming keep the simple things simple and make the advanced things possible with the right mix of declarative configuration (for more built-in features) and programmatic extensibility. The Router team is currently exploring WebAssembly (WASM) as a leading option to enable language-neutral programmatic extensibility – something used by other high-performance networking projects like Envoy.

We’d love your feedback on Gateway customizations that need to be supported in the Router, so if you have a few minutes here’s a survey that would help us ensure all your key use cases are met should you decide to upgrade from the Gateway to the higher performance Router!

Websocket support? Will there be a pattern to support websocket connections through middleware in apollo router for gateway connections? Javascript as a backend technology makes my co-workers cringe…

Just to to be sure there’s an understanding of what’s JavaScript: the Apollo Router is written in Rust and the Apollo Gateway is written in Rust. Hopefully your team will find solace in that since they’d be avoiding JavaScript!

Just to clarify again: Router and Gateway are different incarnations — the former in Rust and the latter in JavaScript! :wink:

With regards to WebSockets: We’re looking at this. It would be good to understand how you use them today. If you’re not using them today, it’d be good to understand specifically what you expect from them and what you’d be hoping for versus another long-held connection (e.g., event streams using HTTP + server-sent events). Could you elaborate?

What’s the recommended approach with Auth? Just pass headers to the subgraph?

looking for a user guide how to configure apollo router jwt authentication

1 Like

I am also interested in this. Have you found anything?
I have found that there is a provision to add auth via a plugin but our entire code is written in JS and devs need to go through Rust to add the plugin. We have a gateway implemented with auth and subgraphs do not worry about authentication. If we need to add auth in subgraphs, there is a lot of duplication. It doesn`t seem ideal.

@prasek @abernix

Yes there’s an example plugin for JWT auth today – but you shouldn’t need to write any Rust code to use the Router as it ships a standalone binary that can be configured using a YAML config file.

Along these lines, we’re looking to add 1st class support for authn/z in the Router. This would include things like: JWT validation, JWT parsing into request context, JWT key rotation (JWKS), OAuth token conversion, and schema-driven authorization. You’d be able to configure this via the router.yaml and for authz subgraph authors would be able to use new directives to require e.g. JWT scopes to access types / fields.

As mentioned in the Router v1.0 blog post:

Our goal is to identify common customizations and elevate them into standard Router features over time, so let us know if you have a Router customization or idea that others in the community could benefit from!

We are also looking to support external Router extensibility (likely via a simple HTTP request/response format), so you can do any custom authn/n using an external network service (e.g. a sidecar in your k8s Pod, in the same availability zone as your router or anywhere on the network). This would allow you to create an external extension for the router in any language or framework that supports HTTP, or even to add an external extension handler directly to existing bespoke services your Gateway or monograph might be talking to already for things like authn/z. External network extensions could be configured via the router.yaml.

Please drop feedback on the following Router issues, or create a new one! :pray: