release: v0.1.0-alpha.5

[abernix]

✨ Features

• Apollo Studio usage reporting agent and operation-level reporting (PR #309, PR #420)

  While there are several levels of Apollo Studio integration, the initial phase of our Apollo Studio reporting focuses on operation-level reporting.

  At a high-level, this will allow Apollo Studio to have visibility into some basic schema details, like graph ID and variant, and per-operation details, including:

  • Overall operation latency
  • The number of times the operation is executed
  • Client awareness reporting, which leverages the apollographql-client-* headers to give visibility into which clients are making which operations.

  This should enable several Apollo Studio features including the Clients and Checks pages as well as the Checks tab on the Operations page.

  Note: As a current limitation, the Fields page will not have detailed field-based metrics and on the Operations page the Errors tab, the Traces tab and the Error Percentage graph will not receive data. We recommend configuring the Router's OpenTelemetry tracing with your APM provider and using distributed tracing to increase visibility into individual resolver performance.

  Overall, this marks a notable but still incremental progress toward more of the Studio integrations which are laid out in #66.

• Complete GraphQL validation (PR #471 via federation-rs#37)

  We now apply all of the standard validations which are defined in the graphql (JavaScript) implementation's default set of "specified rules" during query planning.

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

  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.

  The Router now supports GET requests for query operations, and this is also the foundation for supporting [automated persisted queries] (APQ) in an upcoming release. APQs pair really well with GET requests 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).

🐛 Fixes

• No more double http://http:// in logs (PR #448)

  The server logs will no longer advertise the listening host and port with a doubled-up http:// prefix. You can once again click happily into Studio Explorer!

• Improved handling of Federation 1 supergraphs (PR #446 via federation#1511)

  Our partner team has improved the handling of Federation 1 supergraphs in the implementation of Federation 2 alpha (which the Router depends on and is meant to offer compatibility with Federation 1 in most cases). We've updated our query planner implementation to the version with the fixes.

  This also was the first time that we've leveraged the new federation-rs repository to handle our bridge, bringing a huge developmental advantage to teams working across the various concerns!

• Resolved incorrect subgraph ordering during merge (PR #460)

  A fix was applied to fix the behavior which was identified in Issue #451 which was caused by a misconfigured filter which was being applied to field paths.

[o0Ignition0o]

One feature shall not be in this changelog, otherwise LGTM

[garypen]

Looks good. I like the clear explanation of what studio usage features are enabled.
Approving modulo @o0Ignition0o comment about GET not being on main.