github apollographql/router v0.1.0-alpha.6

latest releases: v2.0.0-preview.0, v1.56.0, v1.56.0-rc.0...
2 years ago

✨ Features

  • Apollo Studio Managed Federation support (PR #498)

    The Router can now automatically download and check for updates on its schema from Studio (via Uplink)'s free, Managed Federation service. This is configured in the same way as Apollo Gateway via the APOLLO_KEY and APOLLO_GRAPH_REF environment variables, in the same way as was true in Apollo Gateway (seen here). This will also enable operation usage reporting.

    Note: It is not yet possible to configure the Router with APOLLO_SCHEMA_CONFIG_DELIVERY_ENDPOINT. If you need this behavior, please open a feature request with your use case.

  • Subgraph header configuration (PR #453)

    The Router now supports passing both client-originated and router-originated headers to specific subgraphs using YAML configuration. Each subgraph which needs to receive headers can specify which headers (or header patterns) should be forwarded to which subgraph.

    More information can be found in our documentation on subgraph header configuration.

    At the moment, when using using YAML configuration alone, router-originated headers can only be static strings (e.g., sent-from-apollo-router: true). If you have use cases for deriving headers in the router dynamically, please open or find a feature request issue on the repository which explains the use case.

  • In-flight subgraph query de-duplication (PR #285)

    As a performance booster to both the Router and the subgraphs it communicates with, the Router will now de-duplicate multiple identical requests to subgraphs when there are multiple in-flight requests to the same subgraph with the same query (never mutations), headers, and GraphQL variables. Instead, a single request will be made to the subgraph and the many client requests will be served via that single response.

    There may be a substantial drop in number of requests observed by subgraphs with this release.

  • Operations can now be made via GET requests (PR #429)

    The Router now supports GET requests for query operations. Previously, the Apollo Router only supported making requests via POST requests. We've always intended on supporting GET support, but needed some additional support in place to make sure we could prevent allowing mutations to happen over GET requests.

  • Automatic persisted queries (APQ) support (PR #433)

    The Router now handles automatic persisted queries (APQ) by default, as was previously the case in Apollo Gateway. APQ support pairs really well with GET requests (which also landed in this release) since they allow read operations (e.g., GET requests) to be more easily cached by intermediary proxies and CDNs, which typically forbid caching POST requests by specification (even if they often are just reads in GraphQL). Follow the link above to the documentation to test them out.

  • New internal Tower architecture and preparation for extensibility (PR #319)

    We've introduced new foundational primitives to the Router's request pipeline which facilitate the creation of composable onion layers. For now, this is largely leveraged through a series of internal refactors and we'll need to document and expand on more of the details that facilitate developers building their own custom extensions. To leverage existing art — and hopefully maximize compatibility and facilitate familiarity — we've leveraged the Tokio Tower Service pattern.

    This should facilitate a number of interesting extension opportunities and we're excited for what's in-store next. We intend on improving and iterating on the API's ergonomics for common Graph Router behaviors over time, and we'd encourage you to open issues on the repository with use-cases you might think need consideration.

  • Support for Jaeger HTTP collector in OpenTelemetry (PR #479)

    It is now possible to configure Jaeger HTTP collector endpoints within the opentelemetry configuration. Previously, Router only supported the UDP method.

    The documentation has also been updated to demonstrate how this can be configured.

🐛 Fixes

  • Studio agent collector now binds to localhost PR #486

    The Studio agent collector will bind to 127.0.0.1. It can be configured to bind to 0.0.0.0 if desired (e.g., if you're using the collector to collect centrally) by using the spaceport.listener property in the documentation.

Don't miss a new router release

NewReleases is sending notifications on new releases.