apollographql/router v0.1.0-alpha.9

on GitHub

❗ BREAKING ❗

• Header propagation configuration changes (PR #599)

  Header manipulation configuration is now a core-plugin and configured at the top-level of the Router's configuration file, rather than its previous location within service-level layers. Some keys have also been renamed. For example:

  Previous configuration

  subgraphs:
    products:
      layers:
        - headers_propagate:
            matching:
              regex: .*

  New configuration

  headers:
    subgraphs:
      products:
        - propagate:
          matching: ".*"

• Move Apollo plugins to top-level configuration (PR #623)

  Previously plugins were all under the plugins: section of the YAML config. However, these "core" plugins are now promoted to the top-level of the config. This reflects the fact that these plugins provide core functionality even though they are implemented as plugins under the hood and further reflects the fact that they receive special treatment in terms of initialization order (they are initialized first before members of plugins).

• Remove configurable layers (PR #603)

  Having plugins and layers as configurable items in YAML was creating confusion as to when it was appropriate to use a layer vs a plugin. As the layer API is a subset of the plugin API, plugins has been kept, however the layer option has been dropped.

• Plugin names have dropped the com.apollographql prefix (PR #602)

  Previously, core plugins were prefixed with com.apollographql.. This is no longer the case and, when coupled with the above moving of the core plugins to the top-level, the prefixing is no longer present. This means that, for example, com.apollographql.telemetry would now be just telemetry.

• Use ControlFlow in checkpoints (PR #602)

  Both checkpoint and async_checkpoint now use std::ops::ControlFlow instead of the Step enum. ControlFlow has two variants, Continue and Break.

• The reporting configuration changes to telemetry (PR #651)

  All configuration that was previously under the reporting header is now under a telemetry key.

✨ Features

• Header propagation now supports "all" subgraphs (PR #599)

  It is now possible to configure header propagation rules for all subgraphs without needing to explicitly name each subgraph. You can accomplish this by using the all key, under the (now relocated; see above breaking changes) headers section.

  headers:
    all:
    - propagate:
      matching: "aaa.*"
    - propagate:
      named: "bbb"
      default: "def"
      rename: "ccc"
    - insert:
      name: "ddd"
      value: "eee"
    - remove:
      matching: "fff.*"
    - remove:
      name: "ggg"

• Update to latest query planner from Federation 2 (PR #653)

  The Router now uses the @apollo/query-planner@2.0.0-preview.5 query planner, bringing the most recent version of Federation 2.

🐛 Fixes

• Content-Type of HTTP responses is now set to application/json (Issue #639)

  Previously, we were not setting a content-type on HTTP responses. While plugins can still set a different content-type if they'd like, we now ensure that a content-type of application/json is set when one was not already provided.

• GraphQL Enums in query parameters (Issue #612)

  Enums in query parameters were handled correctly in the response formatting, but not in query validation. We now have a new test and a fix.

• OTel trace propagation works again (PR #620)

  When we re-worked our OTel implementation to be a plugin, the ability to trace across processes (into subgraphs) was lost. This fix restores this capability. We are working to improve our end-to-end testing of this to prevent further regressions.

• Reporting plugin schema generation (PR #607)

  Previously our reporting plugin configuration was not able to participate in JSON Schema generation. This is now broadly correct and makes writing a syntactically-correct schema much easier.

  To generate a schema, you can still run the same command as before:

  router --schema > apollo_configuration_schema.json
  

  Then, follow the instructions for associating it with your development environment.

• Input object validation (PR #658)

  Variable validation was incorrectly using output objects instead of input objects