We’d love to hear what you think!
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?
- 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 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 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!
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?