GraphQL Federation — Building a Unified API Gateway for Microservices

Posted on: 4/25/2026 6:12:31 AM

As microservice systems grow to tens or hundreds of services, the biggest question is no longer "REST or gRPC?" but rather: how can the frontend make a single request and access data from all services? REST API Gateways handle routing, but they don't solve data composition — when a page needs data from 5-10 different services, the frontend must make multiple API calls and stitch the data together. GraphQL Federation was built to solve exactly this problem: each team owns a subgraph, and the router automatically composes them into a single unified API. This article provides a deep analysis of the architecture, implementation on .NET with HotChocolate, and real-world production lessons.

1. The Problem — When REST API Gateway Falls Short

Imagine a product detail page on an e-commerce platform: you need product information (Product Service), pricing and inventory (Inventory Service), reviews (Review Service), recommendations (Recommendation Service), and seller information (Seller Service). With REST, the frontend must make 5 sequential round-trips to the gateway, each request waiting for the previous one to complete (waterfall pattern).

With GraphQL Federation, the frontend sends 1 single query. The Router automatically fans out to relevant subgraphs in parallel and composes the response.

2. Core Concepts

GraphQL Federation revolves around 3 main components:

3. Federation v2 — Key Improvements

Federation v2 (current version: v2.11) brings significant improvements over v1:

# Product Subgraph — owned by Product Team
extend schema @link(
  url: "https://specs.apollo.dev/federation/v2.11"
  import: ["@key", "@shareable", "@override"]
)

type Product @key(fields: "id") {
  id: ID!
  name: String!
  description: String
  price: Float!
  weight: Float
  sellerId: ID!
  createdAt: DateTime!
}

type Query {
  product(id: ID!): Product
  products(first: Int = 10, after: String): ProductConnection!
}

4. Choosing a Router — Apollo vs Cosmo vs HotChocolate

5. Implementation on .NET with HotChocolate

For .NET teams, HotChocolate v14 is the only production-grade choice. It supports both Apollo Federation v2 spec and ChilliCream's own Fusion ecosystem:

// ProductSubgraph/Program.cs
var builder = WebApplication.CreateBuilder(args);

builder.Services
    .AddGraphQLServer()
    .AddApolloFederation() // Enable Federation v2
    .AddQueryType<ProductQuery>()
    .AddType<ProductType>()
    .AddFiltering()
    .AddSorting()
    .RegisterDbContext<ProductDbContext>();

var app = builder.Build();
app.MapGraphQL();
app.Run();

// Types/ProductType.cs
[Key("id")] // Federation @key directive
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; } = default!;
    public decimal Price { get; set; }
    public float? Weight { get; set; }
    public int SellerId { get; set; }
}

// DataLoader — batch N+1 queries
public class ProductByIdDataLoader : BatchDataLoader<int, Product>
{
    private readonly IDbContextFactory<ProductDbContext> _factory;

    public ProductByIdDataLoader(
        IDbContextFactory<ProductDbContext> factory,
        IBatchScheduler scheduler) : base(scheduler)
    {
        _factory = factory;
    }

    protected override async Task<IReadOnlyDictionary<int, Product>>
        LoadBatchAsync(IReadOnlyList<int> keys, CancellationToken ct)
    {
        await using var ctx = await _factory.CreateDbContextAsync(ct);
        return await ctx.Products
            .Where(p => keys.Contains(p.Id))
            .ToDictionaryAsync(p => p.Id, ct);
    }
}

6. Performance — Is Federation Slower Than REST?

A common concern: "doesn't adding a Router layer slow things down?" Short answer: Router adds slight latency, but total end-to-end time typically decreases thanks to parallel fan-out and elimination of frontend waterfall patterns.

7. Caching — GraphQL's Biggest Challenge

GraphQL's well-known weakness: CDN caching is hard. REST uses GET + Cache-Control headers for easy caching. GraphQL uses POST with different query bodies each time.

8. Apollo Connectors — Integrating REST into Federation

A breakthrough feature in Apollo Router v2: Connectors let you turn REST APIs into subgraphs without writing code. Just declare in the schema:

# Turn REST endpoint into GraphQL subgraph
# No separate server needed — Router calls REST API directly

extend schema
  @link(url: "https://specs.apollo.dev/federation/v2.11", import: ["@key"])
  @link(url: "https://specs.apollo.dev/connect/v0.4", import: ["@source", "@connect"])
  @source(name: "legacy", http: { baseURL: "https://api.legacy.com/v1" })

type Product @key(fields: "id") {
  id: ID!
  name: String!
  legacyData: LegacyProductData
    @connect(
      source: "legacy"
      http: { GET: "/products/{$this.id}" }
      selection: """
        sku
        category: categoryName
        tags: labels
      """
    )
}

9. When Should You Use Federation?

10. Conclusion

GraphQL Federation solves a problem that REST API Gateways cannot: automatically composing data from multiple microservices into a single response, while maintaining each team's autonomy with their own subgraph. With Apollo Router (Rust, 10x faster than legacy gateway), HotChocolate Fusion (deep .NET 10 integration), and features like Connectors (integrate REST without code), Federation is production-ready at scale.

However, Federation isn't for every project. If your system only has 2-3 services and one frontend — REST + BFF is much simpler. Federation truly shines when you have 5+ services, multiple teams, and frontends needing data from multiple sources. Start with 1-2 subgraphs, validate the value, then expand gradually — don't migrate your entire system at once.

References

• Introduction to Apollo Federation — Apollo GraphQL Docs
• What's New in GraphOS Router v2.x — Apollo GraphQL Docs
• GraphQL Federation Gateways Performance Benchmark — The Guild
• Hot Chocolate vs graphql-dotnet in .NET 2026 — Coding Droplets
• GraphQL vs REST: 18 Claims Fact-Checked — WunderGraph
• GraphQL vs REST 2026: Performance Tested — Tech Insider
• GraphQL vs REST vs gRPC: 2026 Decision Framework — Fordel Studios
• Federating .NET GraphQL APIs with Fusion — Medium