GraphQL für Headless CMS: Strapi, Contentful und Magento im Vergleich

1. Warum Headless CMS und GraphQL zusammenpassen

Ein Headless CMS trennt Content-Verwaltung von Präsentation, ausgeliefert wird nur eine API, die beliebige Frontends bedienen kann. GraphQL passt zu diesem Modell besonders gut, weil unterschiedliche Frontends, eine Marketing-Landingpage, eine mobile App, ein Produktkatalog, jeweils andere Feldkombinationen desselben Content-Modells benötigen. Statt für jeden Anwendungsfall einen eigenen REST-Endpunkt zu pflegen, fragt jeder Client über GraphQL für Headless CMS exakt die Felder ab, die er tatsächlich rendert.

Der zweite Grund liegt in der Struktur von Content selbst: Content-Modelle bestehen typischerweise aus verschachtelten, wiederverwendbaren Komponenten, ein Blog-Artikel referenziert einen Autor, der Autor referenziert ein Profilbild, das Profilbild referenziert Metadaten. GraphQL bildet solche Graphen nativ ab, während REST-APIs für dieselbe Struktur entweder tief verschachtelte Responses oder mehrere sequenzielle Requests erzwingen. GraphQL für Headless CMS reduziert damit sowohl die Anzahl der Requests als auch die Menge an ungenutzten Daten im Response.

Alle drei hier verglichenen Plattformen, Strapi, Contentful und Magento, bieten GraphQL heute als vollwertige Alternative zu ihrer REST-API an, unterscheiden sich aber grundlegend darin, wie das Schema entsteht, wer es kontrolliert und wie stark es an die zugrunde liegende Datenstruktur gekoppelt bleibt.

2. Strapi: GraphQL-Plugin und Schema-Generierung

Strapi ist ein selbst gehostetes, Open-Source Headless CMS auf Node.js-Basis. GraphQL ist kein Kernbestandteil, sondern ein offizielles Plugin, das nach der Installation automatisch ein vollständiges Schema aus den im Admin-Panel definierten Content Types generiert, inklusive Queries, Mutations und Filtern für jeden Typ. Diese automatische Generierung ist der größte Vorteil von GraphQL für Headless CMS mit Strapi: Ein neues Feld im Content-Type-Builder erscheint ohne manuellen Schritt sofort im GraphQL-Schema.

// config/plugins.js — enable and configure the GraphQL plugin
module.exports = ({ env }) => ({
  graphql: {
    config: {
      endpoint: "/graphql",
      shadowCRUD: true, // auto-generate queries/mutations from content types
      playgroundAlways: env("NODE_ENV") !== "production",
      depthLimit: 10,   // guard against deeply nested malicious queries
      amountLimit: 100,
    },
  },
});

Die Kehrseite dieser Automatik: Weil das Schema direkt aus der Datenbankstruktur abgeleitet wird, spiegelt es interne Modellierungsentscheidungen oft eins zu eins, was zu weniger elegant benannten Feldern führt, als ein manuell kuratiertes Schema hätte. Strapi erlaubt zwar, das generierte Schema über Resolver-Overrides und Custom-Types anzupassen, dieser Schritt ist aber zusätzlicher Aufwand, den Contentful und Magento in ihren jeweiligen Modellen anders lösen.

3. Contentful: Managed Content API mit GraphQL

Contentful ist ein vollständig verwalteter SaaS-Dienst ohne Selbst-Hosting-Option. Die GraphQL Content API wird nicht aus einem festen Datenbankschema generiert, sondern dynamisch aus den im Contentful-Web-Interface definierten Content Types abgeleitet, inklusive automatisch generierter Filter-Argumente für jedes Feld. Für GraphQL für Headless CMS mit Contentful bedeutet das: Redakteure ohne Entwicklungshintergrund können neue Felder anlegen, die sofort über GraphQL abfragbar sind, ohne dass ein Deployment nötig wird.

# Contentful auto-generates rich filter arguments per field
query BlogPosts {
  blogPostCollection(
    where: { publishedDate_gte: "2026-01-01" }
    order: publishedDate_DESC
    limit: 10
  ) {
    items {
      title
      slug
      author {
        name
        avatar { url }
      }
      body { json }
    }
  }
}

Weil Contentful als reiner SaaS-Dienst betrieben wird, entfällt jede Infrastruktur-Verantwortung, gleichzeitig ist die Anpassbarkeit begrenzt: Custom Resolver oder eigene Business-Logik im GraphQL-Layer sind nicht vorgesehen, komplexere Transformationen müssen im Frontend oder über eine zusätzliche BFF-Schicht (Backend for Frontend) erfolgen. Das grenzt Contentful klar von Strapi ab, wo eigene Resolver direkt im CMS-Prozess laufen können.

4. Magento GraphQL: Commerce-spezifische Anforderungen

Magento ist kein reines Headless CMS, sondern eine E-Commerce-Plattform mit eingebautem GraphQL-Endpunkt, der sowohl Commerce-Entitäten, Produkte, Kategorien, Warenkorb, als auch CMS-Blöcke und -Seiten abdeckt. GraphQL für Headless CMS-Anwendungsfälle treffen bei Magento auf eine völlig andere Ausgangslage: Das Schema ist nicht frei modellierbar, sondern folgt der komplexen EAV-Struktur (Entity-Attribute-Value) des Produktkatalogs, ergänzt um Custom Attributes, die Merchants im Admin-Panel definieren.

# Magento GraphQL blends commerce entities and CMS content in one schema
query ProductWithCmsBlock($sku: String!) {
  products(filter: { sku: { eq: $sku } }) {
    items {
      name
      sku
      price_range {
        minimum_price { final_price { value currency } }
      }
      # Custom EAV attribute defined by merchant in admin panel
      material
    }
  }
  cmsBlocks(identifiers: ["product_page_trust_badges"]) {
    items { identifier content }
  }
}

Der entscheidende Unterschied zu Strapi und Contentful: Bei Magento GraphQL ist Content nie vollständig von Commerce-Logik entkoppelt. Preise, Lagerbestände und Steuerregeln fließen in dieselben Resolver ein, die auch reine Content-Felder ausliefern, was Performance-Optimierung anspruchsvoller macht als bei einem reinen Content-Store. Wer GraphQL für Headless CMS in einem Magento-Kontext einsetzt, kombiniert es in der Praxis meist mit einem separaten Content-System wie Strapi oder Contentful für redaktionelle Inhalte, während Magento GraphQL für Produktdaten zuständig bleibt.

5. Content-Modeling: Components, Content Types und EAV

Die drei Plattformen modellieren Content grundlegend unterschiedlich. Strapi unterscheidet zwischen Collection Types (wiederkehrende Einträge wie Blog-Artikel) und Single Types (einmalige Seiten wie eine Startseite), ergänzt um wiederverwendbare Components, die in mehreren Content Types eingebettet werden können. Contentful kennt nur Content Types mit Feldern, verschachtelte Strukturen entstehen über Referenzfelder auf andere Einträge, was flexibler, aber auch unstrukturierter werden kann, ohne klare Regeln im Team.

Magentos EAV-Modell wiederum ist historisch für Produktkataloge mit stark variierenden Attributsätzen entstanden, ein Schuh braucht andere Attribute als ein Möbelstück, und wurde nie für allgemeines Content-Modeling entworfen. Das zeigt sich direkt im GraphQL-Schema: Magento-Felder wie configurable_options oder price_range haben keine Entsprechung in Strapi oder Contentful, weil dort schlicht kein Commerce-Konzept existiert. Bei der Wahl von GraphQL für Headless CMS sollte die Modellierungsphilosophie der Plattform daher zum tatsächlichen Content-Typ passen, redaktioneller Content und Produktdaten haben grundverschiedene Anforderungen.

6. Caching-Strategien je Plattform

Caching-Verhalten unterscheidet sich stark zwischen den drei Plattformen. Strapi liefert standardmäßig keinen eingebauten Response-Cache, Teams müssen eine eigene Caching-Schicht, etwa über Redis oder einen CDN mit GraphQL-Persisted-Queries, davorschalten. Contentful betreibt als SaaS ein globales CDN und cacht GraphQL-Responses automatisch, allerdings mit Invalidierungsverzögerung von wenigen Sekunden bis zu einer Minute nach einer Content-Änderung.

{
  "cacheStrategy": {
    "strapi": "kein Cache out-of-the-box, Redis/CDN manuell ergänzen",
    "contentful": "globales CDN, automatische Invalidierung mit Verzögerung",
    "magento": "Varnish Full-Page-Cache für Seiten, GraphQL-Layer separat via Redis"
  }
}

Magento nutzt für den GraphQL-Layer typischerweise eine Kombination aus Redis für Session- und Konfigurationsdaten und einem separaten Caching-Layer für teure Resolver, etwa Preisberechnungen mit Steuerregeln. Weil Magento GraphQL-Responses stark personalisiert sein können, angemeldete Kunden sehen andere Preise als Gäste, ist ein naives Full-Response-Caching wie bei Contentful hier nicht anwendbar, stattdessen wird auf Feld- und Resolver-Ebene granularer gecacht.

7. Authentifizierung und Rollenkonzepte im Vergleich

Strapi implementiert Authentifizierung über Rollen und Berechtigungen, die direkt im Admin-Panel pro Content Type und pro GraphQL-Operation konfiguriert werden, standardmäßig über JWT-Tokens. Contentful trennt strikt zwischen einem schreibenden Management-Token für Redakteure und einem separaten, meist öffentlich eingebetteten Read-Only-Token für die GraphQL Content API, wodurch versehentliche Schreibzugriffe über die Content API strukturell ausgeschlossen sind.

Magento GraphQL nutzt für authentifizierte Requests Customer-Tokens, die über eine dedizierte Mutation angefordert werden, kombiniert mit einem separaten Integration-Token-System für serverseitige Zugriffe etwa aus einem Next.js-Backend. Diese Dreiteilung, Customer-Token, Integration-Token und öffentliche Store-View-Zugriffe ohne Token, ist deutlich granularer als die Zwei-Token-Logik von Contentful, spiegelt aber auch die höhere Komplexität eines Commerce-Systems mit personenbezogenen Bestelldaten wider. Wer GraphQL für Headless CMS mit personalisierten Inhalten plant, sollte diese Unterschiede früh im Architekturentwurf berücksichtigen.

8. Query-Performance in der Praxis

Performance-Charakteristika unterscheiden sich signifikant. Strapi-Resolver laufen im selben Node-Prozess wie das CMS und sind daher bei einfachen Queries sehr latenzarm, skalieren aber bei tief verschachtelten Queries mit vielen Relationen schlechter, wenn keine DataLoader-Batching-Strategie implementiert ist. Contentfuls verteilte SaaS-Infrastruktur liefert konstant niedrige Latenzen über CDN-Edge-Nodes, unabhängig vom Standort des anfragenden Clients, verliert diesen Vorteil aber bei stark personalisierten oder ungecachten Queries.

Magento GraphQL zeigt die größte Varianz: Reine Katalog-Queries auf gecachte Kategoriedaten sind schnell, während Resolver mit Preisberechnung, Lagerbestandsprüfung über mehrere Websites und personalisierten Rabatten spürbar langsamer werden, weil sie in Echtzeit gegen die Business-Logik der Plattform rechnen müssen. Für alle drei Plattformen gilt bei GraphQL für Headless CMS: Query-Tiefe und die Anzahl der aufgelösten Relationen bestimmen die Latenz stärker als die reine Content-Menge.

9. Strapi, Contentful und Magento im direkten Vergleich

In der Praxis entscheiden sich viele Teams nicht für eine einzige Plattform, sondern für ein BFF-Layer (Backend for Frontend), das mehrere GraphQL-Quellen zu einer einzigen Schnittstelle für das Frontend zusammenführt. Ein solcher BFF-Layer fragt Strapi oder Contentful für redaktionellen Content ab, Magento GraphQL für Produktdaten, und liefert dem Client ein einheitliches, kombiniertes Schema, ohne dass das Frontend selbst mehrere GraphQL-Clients konfigurieren muss.

# BFF layer schema stitching Strapi content and Magento commerce data
type ProductLandingPage {
  # Resolved from Strapi: editorial hero content and marketing copy
  heroContent: StrapiHeroBlock!
  # Resolved from Magento GraphQL: live price and stock information
  featuredProducts: [MagentoProduct!]!
}

extend type Query {
  productLandingPage(slug: String!): ProductLandingPage
}

Dieser Ansatz für GraphQL für Headless CMS hat einen entscheidenden Vorteil: Jede Plattform bleibt für das zuständig, wofür sie tatsächlich entworfen wurde, Strapi oder Contentful für redaktionelle Flexibilität, Magento GraphQL für korrekte, in Echtzeit berechnete Commerce-Daten. Der BFF-Layer selbst trägt die Komplexität der Zusammenführung, sodass weder das Content-System Commerce-Logik nachbilden noch Magento redaktionelle Freiheit simulieren muss. Die folgende Tabelle fasst die wichtigsten Unterschiede zusammen, als Entscheidungsgrundlage für die Plattformwahl bei einem neuen Headless-Projekt.

10. Zusammenfassung

GraphQL für Headless CMS bedeutet bei Strapi, Contentful und Magento drei grundverschiedene Architekturen unter derselben Query-Sprache. Strapi bietet volle Code-Kontrolle bei eigener Betriebsverantwortung, Contentful liefert eine wartungsfreie SaaS-Lösung mit begrenzter Anpassbarkeit, Magento GraphQL verschmilzt Content mit komplexer Commerce-Logik und eignet sich primär dort, wo Produktdaten im Zentrum stehen. Die Wahl hängt weniger von GraphQL selbst ab, das in allen drei Fällen dieselbe Spezifikation erfüllt, als von der Frage, wer den Content pflegt, wie stark er sich mit Geschäftslogik verzahnt und welche Betriebsressourcen im Team vorhanden sind.

In der Praxis entstehen häufig hybride Architekturen: Magento GraphQL bleibt für Produktkatalog, Warenkorb und Checkout zuständig, während Strapi oder Contentful redaktionelle Landingpages, Blog-Content und Marketing-Kampagnen bedienen. Ein gemeinsames BFF-Layer kann beide GraphQL-Endpunkte für das Frontend zusammenführen, ohne dass Strapi oder Contentful jemals Commerce-Logik übernehmen müssen.

11. FAQ: GraphQL für Headless CMS