Apollo Federation vs. GraphQL Mesh vs. Cosmo: Architektur-Vergleich für verteilte GraphQL-APIs

1. Warum ein einzelnes GraphQL-Schema irgendwann nicht mehr reicht

Ein monolithisches GraphQL-Schema funktioniert hervorragend, solange ein einzelnes Team Typen, Resolver und Deployments verantwortet. Sobald mehrere Domänenteams gleichzeitig an Produkt-, Bestell- und Nutzerdaten arbeiten, wird dieselbe Codebasis zum Nadelöhr: Jede Änderung an einem Typ erfordert Abstimmung mit allen anderen Teams, Deployments blockieren sich gegenseitig, und ein einzelner fehlerhafter Resolver kann die komplette API lahmlegen, auch wenn er nur für ein Nebenfeature zuständig ist.

Eine verteilte GraphQL-Architektur trennt diese Verantwortung entlang fachlicher Grenzen: Jedes Team betreibt seinen eigenen Dienst mit eigenem Deployment-Zyklus, und ein zentraler Einstiegspunkt fügt die Teilschemas zu einem einzigen, für Clients unsichtbaren Supergraph zusammen. Apollo Federation, GraphQL Mesh und Cosmo unterscheiden sich vor allem darin, wie dieser Einstiegspunkt aufgebaut ist und welche Art von Backend er voraussetzt.

2. Apollo Federation: Subgraph-Komposition mit @key und @external

Apollo Federation setzt voraus, dass jeder Backend-Dienst selbst ein natives GraphQL-Subgraph-Schema exponiert und über die Direktive @key markiert, welches Feld eine Entität eindeutig identifiziert. Der zentrale Router lädt beim Start, oder per Managed Federation, einen zusammengesetzten Supergraph-Plan und weiß dadurch, welcher Subgraph welches Feld eines Typs beisteuert, ohne dass ein Client jemals wissen muss, aus wie vielen Diensten eine Antwort tatsächlich zusammengesetzt wird.

Referenziert ein Subgraph einen Typ, den ein anderer Dienst besitzt, markiert die Direktive @external das Feld als extern definiert, und @requires beziehungsweise @provides steuern, welche Zusatzdaten für die Entity-Resolution nötig sind. Dieses Direktiven-System ist mächtig, verlangt aber von jedem Team ein sauberes Verständnis von Entity-Ownership, sonst entstehen zirkuläre Abhängigkeiten zwischen Subgraphs, die sich erst zur Laufzeit als Fehler zeigen.

# Subgraph: products
type Product @key(fields: "id") {
  id: ID!
  name: String!
  price: Float!
  weightInGrams: Int! @external
  shippingEstimate: String @requires(fields: "weightInGrams")
}

# Subgraph: reviews
type Review {
  id: ID!
  rating: Int!
  product: Product!
}

extend type Product @key(fields: "id") {
  id: ID! @external
  reviews: [Review!]!
}

3. Apollo Federation in der Praxis: Router, Entity-Resolution und Query-Planning

Trifft eine Client-Query auf mehrere Subgraphs zu, zerlegt der Apollo Router sie in einen Query-Plan aus mehreren parallelen oder sequenziellen Teilanfragen an die betroffenen Dienste und fügt die Ergebnisse anhand der @key-Felder wieder zusammen. Dieser Plan wird bei Managed Federation zur Build-Zeit validiert, sodass inkompatible Schema-Änderungen schon in der CI-Pipeline auffallen, bevor sie in Produktion landen.

In der Praxis bedeutet das: Der Router selbst führt keine eigene Geschäftslogik aus, sondern orchestriert ausschließlich Anfragen an die Subgraphs, was ihn schlank und horizontal skalierbar hält. Der Preis dafür ist organisatorisch: Jedes neue Subgraph-Team muss sich an die Federation-Spezifikation halten, was bei bestehenden REST- oder SOAP-Diensten ohne natives GraphQL-Schema zusätzlichen Adaptionsaufwand bedeutet.

# router.yaml
supergraph:
  listen: 0.0.0.0:4000
  path: /graphql

telemetry:
  metrics:
    prometheus:
      enabled: true
      listen: 0.0.0.0:9090

include_subgraph_errors:
  all: true

cors:
  origins:
    - https://mironsoft.de

4. GraphQL Mesh: ein GraphQL-Gateway vor beliebigen APIs

GraphQL Mesh verfolgt einen anderen Ansatz: Statt native GraphQL-Subgraphs vorauszusetzen, generiert es aus vorhandenen REST-, gRPC-, SOAP- oder sogar Datenbank-Schnittstellen automatisch ein GraphQL-Schema und stellt es hinter einem einzigen Gateway bereit. Damit eignet sich Mesh besonders für Unternehmen mit gewachsener Systemlandschaft, in der ein nachträgliches Umschreiben aller Backends auf natives GraphQL wirtschaftlich nicht vertretbar wäre.

Jede Quelle wird über einen Handler und optionale Transformer eingebunden: Ein Handler übersetzt beispielsweise eine OpenAPI-Spezifikation automatisch in GraphQL-Typen, während Transformer Feldnamen umbenennen, verschachtelte Antworten glätten oder Caching-Regeln pro Quelle definieren. Dieses deklarative Konfigurationsmodell erspart handgeschriebene Resolver für Standardfälle, verlangt aber saubere Pflege der Mesh-Konfiguration, sobald sich eine der zugrunde liegenden APIs ändert.

# .meshrc.yaml
sources:
  - name: CrmApi
    handler:
      openapi:
        source: https://crm.internal/openapi.json
        baseUrl: https://crm.internal/api

  - name: LegacyOrders
    handler:
      grpc:
        endpoint: legacy-orders.internal:50051
        protoFilePath: ./protos/orders.proto

transforms:
  - rename:
      renames:
        - from: { type: CrmApi_Customer }
          to: { type: Customer }

5. Wann GraphQL Mesh die bessere Wahl ist als Federation

GraphQL Mesh spielt seine Stärke aus, wenn ein Unternehmen mehrere unabhängige Drittsysteme, etwa ein CRM, ein Zahlungsdienstleister und ein internes REST-Legacy-System, unter einer einzigen GraphQL-Oberfläche vereinen will, ohne Zugriff auf deren Quellcode zu haben. Da Mesh direkt auf der öffentlichen Schnittstelle jeder Quelle aufsetzt, entfällt die Notwendigkeit, dass jedes Team eigene Federation-Direktiven pflegt.

Der Nachteil zeigt sich bei sehr komplexen Entity-Beziehungen zwischen den Quellen: Während Apollo Federation Entity-Resolution als Kernfeature mitbringt, muss dieses Verhalten bei GraphQL Mesh oft manuell über zusätzliche Resolver oder Transformer nachgebaut werden, was bei tief verschachtelten Datenmodellen schnell unübersichtlich wird. Mesh eignet sich daher eher für additive Integration als für eng verzahnte, gemeinsam besessene Domänenmodelle.

6. Cosmo: die Open-Source-Alternative zu Apollo GraphOS

Cosmo, entwickelt von WunderGraph, implementiert dieselbe Federation-Spezifikation wie Apollo, also dieselben @key- und @external-Direktiven, ersetzt aber den proprietären Managed-Federation-Dienst von Apollo GraphOS durch eine vollständig quelloffene Router-Implementierung in Go samt eigenem Schema-Registry-Backend. Bestehende Apollo-Subgraphs lassen sich dadurch oft ohne Codeänderung an einen Cosmo-Router anbinden, weil die Kompatibilität auf Spezifikationsebene und nicht auf Vendor-Ebene gesichert ist.

Der zentrale Unterschied liegt im Betriebsmodell: Während Apollo GraphOS als gehosteter Dienst mit nutzungsbasierter Lizenzierung läuft, kann Cosmo vollständig selbst gehostet werden, inklusive Registry, Analytics und Router. Das macht Cosmo attraktiv für Teams mit strengen Datenresidenz-Anforderungen oder für Unternehmen, die laufende Lizenzkosten bei wachsendem Traffic-Volumen vermeiden wollen.

# Install the Cosmo CLI
npm install -g wgc

# Publish a subgraph to the Cosmo registry
wgc subgraph publish products \
  --schema ./products/schema.graphql \
  --routing-url https://products.internal/graphql

# Compose the supergraph and check for breaking changes
wgc federated-graph compose mironsoft-graph
wgc subgraph check products --schema ./products/schema.graphql

7. Cosmo vs. Apollo GraphOS: Router-Performance und Lizenzmodell

Der Cosmo-Router ist in Go geschrieben und für hohen Durchsatz bei niedrigem Speicherbedarf optimiert, während der Apollo Router in Rust implementiert ist und in unabhängigen Benchmarks bei sehr hoher Anfragelast leicht die Nase vorn hat. Für die meisten mittelgroßen Deployments liegt der praktische Unterschied jedoch im Bereich weniger Millisekunden pro Anfrage, sodass die Entscheidung selten allein an der reinen Performance hängt.

Entscheidender ist meist das Lizenzmodell: Apollo GraphOS berechnet nach Requests und Operationen, was bei sehr hohem Traffic zu spürbaren monatlichen Kosten führen kann, während Cosmo als selbst gehostete Open-Source-Lösung nur Infrastrukturkosten verursacht, dafür aber eigenes Betriebs-Know-how für Registry, Metriken und Alerting voraussetzt, das bei Apollo GraphOS als Managed Service mitgeliefert wird.

# cosmo-router-config.yaml
version: "1"
graph:
  token: "${COSMO_GRAPH_API_TOKEN}"

telemetry:
  metrics:
    otlp:
      enabled: true
      endpoint: http://otel-collector:4318

traffic_shaping:
  router:
    max_request_body_size: 5MB

8. Teamstruktur und Governance: welcher Ansatz zu welcher Organisation passt

Apollo Federation und Cosmo setzen implizit voraus, dass jedes Domänenteam die Verantwortung für sein eigenes Subgraph-Schema übernimmt, inklusive Schema-Reviews, Breaking-Change-Erkennung und Versionierung. Das passt gut zu Organisationen, die bereits nach dem Prinzip eigenständiger Domänenteams mit klaren Bounded Contexts arbeiten, etwa im Sinne von Domain-Driven Design, weil sich die technische Grenze der Subgraphs direkt an die fachliche Grenze der Teams anlehnt.

GraphQL Mesh passt dagegen eher zu einer zentralisierten API-Plattform-Organisation, in der ein einzelnes Team die GraphQL-Fassade über fremde, oft nicht selbst kontrollierte Systeme pflegt. Hier liegt die Governance-Last bei genau diesem einen Team, während die Quellsysteme selbst von ihren jeweiligen Eigentümern unabhängig weiterentwickelt werden können, ohne dass diese sich um Federation-Konzepte kümmern müssen.

9. Entscheidungskriterien: Budget, Teamgröße und bestehende Systemlandschaft

Wer bereits mehrere Teams mit eigenen, nativen GraphQL-Diensten betreibt und Wert auf einen gehosteten, vollständig verwalteten Betrieb mit Schema-Registry, Metriken und Change-Checks legt, ist bei Apollo Federation über Apollo GraphOS gut aufgehoben, sollte aber die laufenden Lizenzkosten in die Budgetplanung einrechnen. Wer dieselbe Spezifikation nutzen, aber selbst hosten und Lizenzkosten vermeiden will, findet in Cosmo eine kompatible, quelloffene Alternative.

Wer dagegen primär bestehende REST-, gRPC- oder Legacy-Systeme unter einer gemeinsamen GraphQL-Oberfläche bündeln will, ohne deren Quellcode anzufassen, kommt mit GraphQL Mesh schneller ans Ziel als mit einer nachträglichen Federation-Migration. Die folgende Tabelle fasst die wichtigsten Unterschiede der drei Ansätze zusammen.

10. Zusammenfassung

11. FAQ: Apollo Federation, GraphQL Mesh und Cosmo: Das Wichtigste auf einen Blick