Fusion 16.5: The Gateway for Everyone

Michael Staib·2026-07-12·8 min read

Share this post on XShare this post on LinkedIn

• fusion
• graphql
• federation
• apollo-federation
• dotnet
• aspnetcore

Fusion 16.5 is here. It delivers another major leap in performance and introduces full support for Apollo Federation.

Fusion is now the only gateway that fully supports both GraphQL Federation (the Composite Schema Specification) and Apollo Federation. We did not bolt on a thin connector layer but integrated Apollo Federation into the core of Fusion. You can freely mix and match GraphQL Federation and Apollo Federation subgraphs in the same graph. Existing services can stay on Apollo Federation, while new subgraphs can adopt the newer open standard and its expanding set of capabilities.

The new Apollo Federation connector achieves a perfect score in The Guild's federation gateway audit, passing all 199 tests across all 46 suites. So far, only Hive Router and our own Fusion Gateway have achieved a perfect score.

With Fusion, you get one gateway for every federation graph. It combines complete compatibility and market-leading performance with the full power of C# and ASP.NET Core.

The only gateway for both federation standards#

The newer GraphQL Federation standard represents where we want federation to go. But we also know that many of you have already invested heavily in Apollo Federation. Fusion lets you protect that investment and adopt new capabilities one subgraph at a time without forcing a migration.

There is no schema conversion or Fusion-specific integration required to compose an Apollo Federation subgraph. Your subgraph keeps its existing Federation 2 schema and exposes it through _service as it does today. You only need to tell Fusion where it can fetch the schema and where the gateway can reach the subgraph at runtime:

{
  "name": "Products",
  "transports": {
    "http": {
      "url": "http://localhost:4001/graphql"
    }
  },
  "extensions": {
    "chillicream": {
      "apolloFederationSupport": {
        "version": "2.0"
      }
    }
  }
}

Compose the subgraph with Nitro:

nitro fusion compose \
  --source-schema-url http://localhost:4001/graphql \
  --source-schema-settings-file ./products/schema-settings.json \
  --archive gateway.far

The apolloFederationSupport setting tells Nitro to fetch the SDL by querying _service { sdl }. Fusion then translates directives such as @key, @requires, @provides, and @interfaceObject into its internal composition model.

At runtime, Fusion continues to speak Apollo Federation to that subgraph through the _entities field. GraphQL Federation subgraphs, by contrast, use their native lookup fields. Both models can participate in the same graph and even the same query plan. Fusion's query planner treats them identically.

The open future of federation runs through Fusion#

GraphQL Federation is an open specification developed by Apollo, ChilliCream, The Guild, and other contributors from across the GraphQL community. What began as the Composite Schema Specification is now the shared foundation for how distributed GraphQL systems compose, plan, and execute.

Fusion implements that model today, and the latest version shows how much further federation can go.

The new @require model goes far beyond basic field dependencies. A requirement can map nested source data into typed resolver arguments, construct input objects, work across interfaces, and describe precisely what a resolver needs at runtime. Subgraph authors get explicit contracts, while Fusion gets the information it needs to build better query plans.

For example, a Shipping subgraph can calculate a delivery estimate using product data owned by other subgraphs. A field selection map declares both the required data and how Fusion should inject it into the resolver argument.

# Shipping subgraph
type Product {
  id: ID!
  deliveryEstimate(
    zip: String!
    dimensions: ProductDimensionInput!
      @require(
        field: """
        {
          weight,
          length: dimensions.length,
          width: dimensions.width,
          height: dimensions.height
        }
        """
      )
  ): Int!
}

input ProductDimensionInput {
  weight: Float!
  length: Float!
  width: Float!
  height: Float!
}

At the code level, this is much cleaner than receiving a representation and manually extracting untyped data. The resolver knows exactly which data it will receive and where it will appear. It also controls how that data maps onto its own types. In this example, the nested dimension fields are lifted into a strongly typed ProductDimensionInput record.

[ObjectType<Product>]
public static partial class ProductNode
{
    public static int GetDeliveryEstimate(
        [Parent] Product product,
        string zip,
        [Require(
            """
            {
              weight,
              length: dimensions.length,
              width: dimensions.width,
              height: dimensions.height
            }
            """)]
        ProductDimensionInput dimensions)
        => ShippingCalculator.Estimate(zip, dimensions);
}

public sealed record ProductDimensionInput(
    float Weight,
    float Length,
    float Width,
    float Height);

Clients provide only the zip argument. Fusion fetches weight and the nested dimension fields from whichever subgraphs own them, builds the ProductDimensionInput, and passes it to the Shipping resolver. Because the dependency is part of the schema, Fusion can validate that every field exists, is reachable, and has a compatible type during composition. A missing dependency becomes a composition error instead of a runtime failure.

The overhauled interface object model addresses long-standing requests from the community. A subgraph can add behavior to an interface without repeating that behavior across every implementing type. Concrete types can replace projected behavior explicitly, and Fusion can carry those relationships across source schemas and federation protocols.

Imagine that the Catalog subgraph owns a Media interface implemented by books and movies:

# Catalog subgraph
type Query {
  mediaById(id: ID!): Media @lookup
}

interface Media {
  id: ID!
  title: String!
}

type Book implements Media @key(fields: "id") {
  id: ID!
  title: String!
}

type Movie implements Media @key(fields: "id") {
  id: ID!
  title: String!
}

The Analytics subgraph can add views to every kind of media without knowing that Book or Movie exists:

# Analytics subgraph
type Query {
  mediaByKey(id: ID!): Media @lookup @internal
}

type Media @interfaceObject @key(fields: "id") {
  id: ID!
  views: Int!
}

Composition projects views onto the Media interface and all of its implementations. When Catalog adds another media type, Analytics does not need to change.

If books need their own implementation of views, Catalog can replace the projected default explicitly:

type Book implements Media @key(fields: "id") {
  id: ID!
  title: String!
  views: Int! @implement
}

Book now owns its implementation of views, while Movie and every other media type continue to use the default from Analytics. The @implement marker makes that intent explicit. If the field is redeclared without it, Fusion reports the conflict during composition instead of silently choosing an implementation.

This is a leap forward for distributed GraphQL. Apollo Federation support means you can adopt that future at your own pace, while the services you already operate continue to run unchanged.

Supporting both federation models was one challenge. Doing it without compromising performance was another. The answer goes back to one of the earliest and most important decisions we made for Fusion.

We stayed with .NET, and it paid off#

Staying with C# and .NET was not the obvious bet in a gateway market moving to Rust and Go. It was ours.

Fusion 16.5 shows why that decision was the right one for us.

Fusion is built on ASP.NET Core, so it stands on the server platform Microsoft has spent years hardening and optimizing. Authentication, dependency injection, configuration, observability, HTTP connection management, and resilience for inter-service communication all use the same platform capabilities as the rest of your ASP.NET Core applications.

We also take full advantage of the lower-level APIs the .NET team has introduced over time. Fusion uses request-scoped memory arenas and references data in existing representations instead of copying it. This gives us precise control over the hot path without giving up managed code or the .NET ecosystem.

That architecture also works in your favor when you need to extend the gateway. Fusion is a .NET library, so you can extend it using ordinary C#. You can implement a subscription provider, add data masking, influence the query planner, or integrate your own authentication provider without learning a separate extension language or building around a complex hook system.

The fastest gateway where it matters#

Choosing .NET did not mean sacrificing performance. On the contrary, Fusion has become the fastest gateway on the market, beating every competitor.

Consider the benchmark that simulates real-world load with constant traffic and downstream latency. It runs a complex query across 50 concurrent virtual users (VUs), exercises lookups and requirements, and adds 4 ms of latency to every downstream call. Fusion 16.5 now tops this benchmark.

The progression across the published Fusion results is clear. Median throughput increased from 1,441 requests per second with Fusion 16.0 to 1,830 with Fusion 16.4 and 1,856 with Fusion 16.5. That is an improvement of nearly 29% since Fusion 16.0. Performance remains a constant focus for us, and we continue to invest in it with every release.

We measure three benchmark categories:

• Constant with latency shows how a gateway performs in real-world scenarios where downstream services make database calls and perform other I/O-bound work. Every downstream call adds 4 ms of latency, and the test runs with 50 concurrent VUs.

• Constant without latency is a lab experiment in which the downstream services add no latency. It shows the theoretical throughput of a gateway when downstream latency is not a factor.

• Burst shows how gateways handle sudden traffic spikes. The benchmark starts with a constant base load of 50 VUs, spikes to 500 VUs, and then settles back to 50 VUs.

The gateway benchmark suite runs daily and is regularly updated to test new gateway versions. All benchmarks run on dedicated hardware to produce predictable, comparable results. Each gateway runs on a clean system. After every benchmark run, we reset the system to its original state and restart it before testing the next gateway.

For every federation graph#

Fusion 16.5 changes what teams can expect from a federation gateway.

It is the only gateway that brings GraphQL Federation and Apollo Federation together. It passes every case in The Guild's federation audit and leads in real-world performance. And it delivers all of that as an extensible ASP.NET Core application built with C# and .NET.

You no longer have to choose between compatibility, performance, and extensibility.

Keep the graph you have. Build the graph you want. Move one subgraph at a time.

If you are moving from Apollo Federation, read Coming from Apollo Federation. If you are starting a new graph, follow the Fusion getting started guide. Then join us on Slack and show us what you are building.