Federation, Stitching und BFF: Wann welche Architektur?

1. Das gemeinsame Problem: mehrere GraphQL-Quellen koordinieren

Wer ein einzelnes GraphQL-Schema betreibt, das von einem Team gepflegt wird, braucht weder Federation noch Stitching noch BFF. Diese Muster entstehen aus einem konkreten Problem: Mehrere Teams pflegen separate Services, jeder Service hat seine eigene GraphQL-API, und das Frontend soll trotzdem einen einzigen Endpunkt ansprechen. Die drei Architekturmuster – Federation, Stitching und BFF – lösen dieses Problem auf unterschiedliche Arten, mit unterschiedlichen Trade-offs in Komplexität, Ownership und Laufzeitverhalten.

Im E-Commerce-Kontext ist dieses Problem besonders ausgeprägt: Produktdaten kommen aus Magento, Kundenpräferenzen aus einem CRM, Bewertungen aus einem dedizierten Review-Service, Lagerbestände aus einem WMS. Das Frontend braucht Daten aus all diesen Quellen gleichzeitig – möglichst in einem einzigen Request. Drei Requests vom Browser an drei verschiedene Endpunkte sind keine Lösung, weil sie Netzwerklatenz summieren und die Koordinationslogik ins Frontend verlagern.

2. Apollo Federation v2: verteiltes Schema mit klarer Ownership

Apollo Federation ist ein Standard für verteilte GraphQL-Schemata, bei dem jeder Service (Subgraph) einen Teil des gesamten Schemas besitzt. Ein zentraler Router – der Gateway – nimmt Queries entgegen, zerlegt sie in Teilqueries für die relevanten Subgraphen, führt die Ergebnisse zusammen und gibt eine einzige Antwort zurück. Der Schlüssel zu Federation ist das @key-Direktiv: Es erlaubt einem Subgraphen, Entitäten aus anderen Subgraphen zu referenzieren, ohne deren gesamtes Schema importieren zu müssen.

Federation eignet sich, wenn klare Team-Ownership-Grenzen existieren: Team A besitzt den Produkt-Subgraphen, Team B den Kunden-Subgraphen. Jedes Team kann sein Schema unabhängig weiterentwickeln, solange die deklarierten Entitäten und Keys stabil bleiben. Der Router kennt das zusammengesetzte Schema und plant die Query-Ausführung automatisch. Das ist mächtig – aber auch komplex: Federation v2 mit Apollo Router hat eigene Konzepte wie Shareable-Felder, Override-Direktiven und den Query-Planner, die man verstehen muss, bevor man produktiv damit arbeitet.

# Product subgraph (Magento or dedicated catalog service)
extend schema
  @link(url: "https://specs.apollo.dev/federation/v2.3",
        import: ["@key", "@shareable"])

type Product @key(fields: "sku") {
  sku: String!
  name: String!
  price: Float!
}

type Query {
  product(sku: String!): Product
  products(search: String, pageSize: Int = 20): [Product!]!
}

# Review subgraph (separate service)
# extends Product from catalog subgraph
extend schema
  @link(url: "https://specs.apollo.dev/federation/v2.3",
        import: ["@key", "@external", "@requires"])

type Product @key(fields: "sku") {
  sku: String! @external
  reviews: [Review!]!
}

type Review {
  id: ID!
  rating: Int!
  comment: String
}

3. Schema Stitching: pragmatisch aber komplex

Schema Stitching ist der ältere Ansatz: Mehrere GraphQL-Schemata werden programmatisch zu einem einzigen zusammengebaut. Im Unterschied zu Federation gibt es keinen formalen Standard – die Zusammensetzung erfolgt durch Code, typischerweise in Node.js mit Tools wie GraphQL Tools oder The Guild's @graphql-tools/stitch. Das macht Stitching pragmatischer und schneller einzurichten als Federation, aber auch anfälliger für unerwartete Interaktionen beim Zusammenführen von Typen aus verschiedenen Quellen.

Stitching passt gut in Situationen, wo man kurzfristig mehrere bestehende GraphQL-APIs zusammenführen möchte, ohne die einzelnen Services ändern zu können. Es eignet sich für kleinere Teams oder für interne Plattformen, wo die Ownership-Grenzen weniger scharf sind. Der Preis ist höhere Wartungskomplexität in der Stitching-Schicht selbst: Typkonflikte, Schema-Evolution und Caching sind schwerer zu kontrollieren als in einem Federation-Setup mit formalem Schema-Registry.

4. Backend for Frontend: maßgeschnittene API-Schicht

Das Backend-for-Frontend-Muster (BFF) ist kein GraphQL-spezifisches Konzept, passt aber sehr gut zu GraphQL: Für jedes Frontend – Web-App, Mobile App, Kiosk – wird eine dedizierte API-Schicht gebaut, die genau die Daten liefert, die dieses Frontend benötigt. In einem GraphQL-BFF bedeutet das: ein eigenes GraphQL-Schema, das nur die für das jeweilige Frontend relevanten Felder exponiert, und Resolver, die die Daten aus verschiedenen Backend-Services aggregieren.

Ein BFF ist keine Alternative zu Federation oder Stitching, sondern eine komplementäre Schicht: Das BFF kann selbst Subgraph einer Federation sein oder intern Schema Stitching verwenden. Der Vorteil des BFF ist die maximale Freiheit in der API-Gestaltung: Das Frontend-Team kann sein Schema so gestalten, wie es für das Frontend optimal ist, ohne Rücksicht auf die Backend-Services-Struktur nehmen zu müssen. Der Nachteil: Bei mehreren Frontends entsteht schnell ein Zoo von BFFs, die jeweils ihre eigene Business-Logik entwickeln und schwer zu koordinieren sind.

# BFF schema: optimized for the web storefront's homepage
# Aggregates data from catalog, promotions and recommendation services
type HomepageData {
  hero_banner: HeroBanner
  featured_products: [FeaturedProduct!]!
  active_promotions: [Promotion!]!
  personalized_recommendations: [ProductRecommendation!]!
}

type FeaturedProduct {
  sku: String!
  name: String!
  image_url: String!
  price: Float!
  discount_percentage: Float
}

type HeroBanner {
  headline: String!
  subheadline: String
  cta_label: String!
  cta_url: String!
  background_image_url: String!
}

type Query {
  homepage: HomepageData!
    @resolver(class: "BFF\\Web\\Resolver\\Homepage")
}

5. Entscheidungsrahmen: wann welches Muster passt

Die Entscheidung zwischen Federation, Stitching und BFF hängt von drei Faktoren ab: Teamgröße und Ownership-Struktur, Laufzeitanforderungen und Änderungshäufigkeit, sowie dem bestehenden technologischen Stack. Federation setzt voraus, dass Teams bereit sind, ihre Services nach Federation-Standards zu strukturieren – mit @key-Direktiven, Entitätsdefinitionen und einem Schema-Registry. Das ist eine Investition, die sich erst ab einer gewissen Teamgröße und Systemkomplexität rentiert.

Stitching ist die schnellste Lösung für den Fall, dass man mehrere bestehende APIs zusammenführen muss, ohne die Services ändern zu können. Es ist aber keine langfristige Architektur für große Teams, weil die zentrale Stitching-Schicht zum Engpass und zur Blackbox werden kann. Ein BFF ist die richtige Wahl, wenn ein Frontend-Team schnell und unabhängig agieren muss, ohne auf Backend-Service-Änderungen warten zu wollen – auch auf Kosten einer möglichen Logik-Duplizierung zwischen mehreren BFFs.

6. Gateway-Konzepte und Laufzeitanforderungen

Der Router oder Gateway in einer Federation ist kritische Infrastruktur: Er nimmt alle Queries entgegen, plant die Ausführung über Subgraphen, sendet Teilqueries und führt Ergebnisse zusammen. Apollo Router (in Rust implementiert) ist derzeit die performanteste Option für Apollo Federation. Für kleinere Setups ist Apollo Gateway (Node.js) ausreichend. Beide haben unterschiedliche Caching-, Authentifizierungs- und Rate-Limiting-Konzepte, die im Gateway konfiguriert werden können – unabhängig von den Subgraphen.

Laufzeitanforderungen für Federation sind höher als für eine einzelne GraphQL-API: Der Gateway muss hochverfügbar sein, weil er ein Single Point of Failure für alle Frontends ist. Schema-Updates in Subgraphen müssen kompatibel sein, bevor sie deployed werden – dafür gibt es Schema-Registry-Workflows mit Breaking-Change-Erkennung. Diese Operationsanforderungen sind ein häufig unterschätzter Aufwand beim Einstieg in Federation.

7. Magento als Subgraph in einer Federation

Magento kann als Subgraph in einer Apollo Federation integriert werden, aber nicht nativ: Magento GraphQL unterstützt Federation-Direktiven nicht out of the box. Die Lösung ist ein dünner Proxy-Subgraph, der das Magento-GraphQL-Schema nach außen exponiert und dabei Federation-kompatible @key-Direktiven hinzufügt. Dieser Proxy kann in Node.js oder PHP implementiert werden und translated zwischen Magentos nativer GraphQL-API und dem Federation-Standard.

Der praktischere Ansatz für die meisten Projekte: Magento bleibt ein eigenständiger GraphQL-Endpunkt, und ein BFF-Layer aggregiert Magento-Daten mit Daten aus anderen Quellen. Dieses Muster ist einfacher zu betreiben und vermeidet die Komplexität eines vollständigen Federation-Setups – auf Kosten einer weniger formalen Ownership-Trennung. Für reine Headless-Commerce-Projekte mit einem einzigen Frontend-Team ist das BFF-Muster meist die pragmatischere Wahl.

# Thin federation-compatible proxy for Magento GraphQL
# Adds @key directives to make Magento types federation-aware
extend schema
  @link(url: "https://specs.apollo.dev/federation/v2.3",
        import: ["@key"])

# Magento Product type exposed as federation entity
type MagentoProduct @key(fields: "sku") {
  sku: String!
  name: String!
  price_range: PriceRange!
  categories: [Category!]!
}

type PriceRange {
  minimum_price: Price!
  maximum_price: Price!
}

type Price {
  final_price: Money!
  regular_price: Money!
}

type Money {
  value: Float!
  currency: String!
}

type Query {
  magentoProduct(sku: String!): MagentoProduct
  magentoProducts(search: String, pageSize: Int = 20): [MagentoProduct!]!
}

8. Typische Fallstricke bei allen drei Mustern

Bei Federation ist der häufigste Fallstrick die unreflektierte Verwendung von @extends für Entitäten, die eigentlich @key-Entities mit @external-Feldern sein sollten. Federation v2 hat hier die Konzepte vereinfacht, aber die Lernkurve ist steil. Ein zweiter Fallstrick ist die fehlende Schema-Registrierung vor dem Deploy: Wer Subgraph-Schemas ändert, ohne sie gegen den Router-Kompositionscheck zu validieren, riskiert einen Gateway-Fehler, der alle Frontends gleichzeitig trifft.

Bei Stitching ist das häufigste Problem die stille Überschreibung von Feldern: Wenn zwei Schemata einen Typ mit gleichem Namen aber unterschiedlichen Feldern definieren, gewinnt je nach Konfiguration eines der Schemata und die Felder des anderen werden stillschweigend verworfen. Bei BFF ist das häufigste Problem die Business-Logik-Duplizierung: Jeder BFF reimplementiert dieselben Validierungsregeln, was zu Inkonsistenzen zwischen Frontends führt, wenn die Regeln sich ändern.

9. Zusammenfassung

Federation, Stitching und BFF sind keine konkurrierenden Standards, sondern komplementäre Werkzeuge für unterschiedliche Situationen. Federation ist die richtige Wahl für große Plattformen mit mehreren autonomen Teams und klaren Service-Ownership-Grenzen. Stitching passt für schnelle Integration bestehender APIs ohne Service-Änderungen. Das BFF-Muster ist optimal für schnelle, frontend-zentrierte Entwicklung, wo ein dediziertes Team die API-Schicht vollständig kontrollieren soll.

Die wichtigste Erkenntnis: Alle drei Muster erhöhen die Systemkomplexität gegenüber einem einzelnen GraphQL-Endpunkt. Diese Komplexität ist gerechtfertigt, wenn die Probleme – verteilte Teams, separate Services, unterschiedliche Frontend-Anforderungen – real und dauerhaft sind. Wer Komplexität hinzufügt, bevor das Problem real ist, zahlt den Preis ohne den Nutzen zu erhalten.

10. Direktvergleich: Federation vs. Stitching vs. BFF

11. FAQ: Federation, Stitching und BFF