v0.1.0-alpha.3

🚀🌒 Public alpha release

✨ Features

• Trace sampling #228: Tracing each request can be expensive. The router now supports sampling, which allows us to only send a fraction of the received requests.

• Health check #54

🐛 Fixes

• Schema parse errors #136: The router wouldn't display what went wrong when parsing an invalid Schema. It now displays exactly where a the parsing error occured, and why.

• Various tracing and telemetry fixes #237: The router wouldn't display what went wrong when parsing an invalid Schema. It now displays exactly where a the parsing error occured, and why.

• Query variables validation #62: Now that we have a schema parsing feature, we can validate the variables and their types against the schemas and queries.

v0.1.0-alpha.2

🚀🌒 Public alpha release

✨ Features

• JSON log output

🐛 Fixes

• Fix Open Telemetry Zipkin report errors #180

v0.1.0-alpha.1

🐛 Fixes

• Handle commas in the @join__graph directive parameters #101

  There are several accepted syntaxes to define @join__graph parameters. While we did handle whitespace separated parameters such as @join__graph(name: "accounts" url: "http://accounts/graphql")for example, we discarded the url in@join__graph(name: "accounts", url: "http://accounts/graphql") (notice the comma). This pr fixes that.

• Invert subgraph URL override logic #135

  Subservices endpoint URLs can both be defined in supergraph.graphql and in the subgraphs section of the configuration.yml file. The configuration now correctly overrides the supergraph endpoint definition when applicable.

• Parse OTLP endpoint address #156

  The router OpenTelemetry configuration only supported full URLs (that contain a scheme) while OpenTelemtry collectors support full URLs and endpoints, defaulting to https. This pull request fixes that.

📚 Documentation

• A lot of configuration examples and links have been fixed (#117, #120, #133)

🙏 Thank you!

Special thanks to @sjungling, @hsblhsn, @martin-dd, @Mithras and @vvakame for trying out the router, opening issues and documentation fixes! 🚀

v0.1.0-alpha.0

🚀🌒 Initial public alpha release

An alpha or beta release is in volatile, active development. The release might not be feature-complete, and breaking API changes are possible between individual versions.

See our release stages for more information.

✨ Features

• Federation 2 alpha

  The Apollo Router supports the new alpha features of Apollo Federation 2, including its improved shared ownership model and enhanced type merging. As new Federation 2 features are released, we will update the Router to bring in that new functionality.

• Supergraph support

  The Apollo Router supports supergraphs that are published to the Apollo Registry, or those that are composed locally. Both options are enabled by using Rover to produce (rover supergraph compose) or fetch (rover supergraph fetch) the supergraph to a file. This file is passed to the Apollo Router using the --supergraph flag.

  See the Rover documentation on supergraphs for more information!

• Query planning and execution

  The Apollo Router supports Federation 2 query planning using the same implementation we use in Apollo Gateway for maximum compatibility. In the future, we would like to migrate the query planner to Rust. Query plans are cached in the Apollo Router for improved performance.

• Performance

  We've created benchmarks demonstrating the performance advantages of a Rust-based Apollo Router. Early results show a substantial performance improvement over our Node.js based Apollo Gateway, with the possibility of improving performance further for future releases.

  Additionally, we are making benchmarking an integrated part of our CI/CD pipeline to allow us to monitor the changes over time. We hope to bring awareness of this into the public purview as we have new learnings.

  See our blog post for more.

• Apollo Sandbox Explorer

  Apollo Sandbox Explorer is a powerful web-based IDE for creating, running, and managing GraphQL operations. Visiting your Apollo Router endpoint will take you into the Apollo Sandbox Explorer, preconfigured to operate against your graph.

• Introspection support

  Introspection support makes it possible to immediately explore the graph that's running on your Apollo Router using the Apollo Sandbox Explorer. Introspection is currently enabled by default on the Apollo Router. In the future, we'll support toggling this behavior.

• OpenTelemetry tracing

  For enabling observability with existing infrastructure and monitoring performance, we've added support using OpenTelemetry tracing. A number of configuration options can be seen in the configuration documentation under the opentelemetry property which allows enabling Jaeger or OTLP.

  In the event that you'd like to send data to other tracing platforms, the OpenTelemetry Collector can be run an agent and can funnel tracing (and eventually, metrics) to a number of destinations which are implemented as exporters.

• CORS customizations

  For a seamless getting started story, the Apollo Router has CORS support enabled by default with Access-Control-Allow-Origin set to *, allowing access to it from any browser environment.

  This configuration can be adjusted using the CORS configuration in the documentation.

• Subgraph routing URL overrides

  Routing URLs are encoded in the supergraph, so specifying them explicitly isn't always necessary.

  In the event that you have dynamic subgraph URLs, or just want to quickly test something out locally, you can override subgraph URLs in the configuration.

  Changes to the configuration will be hot-reloaded by the running Apollo Router.

📚 Documentation

The beginnings of the [Apollo Router's documentation] is now available in the Apollo documentation. We look forward to continually improving it!

• Quickstart tutorial

  The quickstart tutorial offers a quick way to try out the Apollo Router using a pre-deployed set of subgraphs we have running in the cloud. No need to spin up local subgraphs! You can of course run the Apollo Router with your own subgraphs too by providing a supergraph.

• Configuration options

  On our configuration page we have a set of descriptions for some common configuration options (e.g., supergraph and CORS) as well as a full configuration file example of the currently supported options.

👀 Ahead...

We'll be working to open issues and surface designs about these things and more, as the planning progresses. Follow our ROADMAP.md for more details as they become available and we'll link to issues as they're available. We look forward to your participation!

• Apollo Studio integrations

  We'll be building out stories for Apollo Studio, including:

  • Tracing
  • Metrics reporting
  • Schema reporting

  We'd like to make the Apollo Router as much as part of the Studio story as Apollo Gateway is today.

• Newer Federation 2 features

  As new Apollo Federation 2 features are released, we'll integrate those updates into the Router. In most cases, this will be just as simple as updating the Apollo Router's dependencies.

• More customizations

  We're excited about a number of opportunities for customizing behavior, including exploring options for:

  • Header manipulation
  • Request context propagation
  • Dynamic routing
  • Authorization
  • Auditing

  We hope to provide first-class experiences for many of the things which required a more-than-ideal amount of configuration.

• Specification compliance

  We're still working on making the Apollo Router fully GraphQL specification compliant. This will be a continued effort and is also embodied in the Apollo Router's design principles.

  Until we finish this work, there may be responses returned to the clients which are not fully specification compliant, including artifacts of Federation query plan execution. (e.g., the inclusion of additional metadata).

• OpenTelemetry/Prometheus metrics

  These will compliment the existing OpenTelemetry traces which we already support. It will help to paint a clearer picture of how the Apollo Router is performing and allow you to set alerts in your favorite alerting software.

• Structured logging

  The logs that are produced from the Apollo Router should integrate well with existing log facilities. We'll be adding configuration to enable this (e.g., JSON-formatted logging).

• Continued performance tuning

  The Apollo Router is already fast, but we'll be looking for more ways to make it faster. We'll be setting up CI/CD performance measurements to track regressions before they end up in user's deployments and to understand the cost of new features we introduce.

• Hardening

  The Router will need new functionality to remain performant. This will include exploring options for rate-limiting, payload size checking, reacting to back-pressure, etc.