Der E-Commerce-Markt hat sich in den letzten Jahren stark gewandelt. Immer mehr erwarten sich Ihre Kundinnen und Kunden reibungslos funktionierende Kauferlebnisse über verschiedene Kanäle hinweg – sei es die klassische Website, mobile Apps oder Smart Displays und Sprachassistenten. Klassische, monolithische Shopsysteme sind mit diesen Anforderungen bald am Ende. An dieser Stelle setzt Shopware 6 mit seiner konsequent API-first gebauten Architektur an, die sogenannte Headless-Commerce-Ansätze möglich macht.
Was heißt Headless Commerce technisch?
Headless beschreibt gewissermaßen die Entkopplung von Frontend und Backend. In einem klassischen Shopsystem sind Warenwirtschaft, Datenbank, Geschäftslogik und Darstellungsschicht eng miteinander verzahnt. Änderungen an der Oberfläche gehen oft tief in den Systemkern und machen Wartung und Weiterentwicklung schwierig. Bei einem Headless-Ansatz kommuniziert das Frontend ausschließlich über definierte Schnittstellen mit dem Backend. Die Präsentationsschicht ist damit austauschbar, ohne dass irgendwo in der Geschäftslogik Anpassungen nötig sind.
Um dies zu ermöglichen, stellt Shopware 6 drei wesentliche APIs zur Verfügung. Die Store API wird für den Kontakt mit den Endkunden-Frontends verwendet und deckt alle für die Nutzung wichtigen Funktionen ab: Produkte abrufen, Warenkorb, Checkout, Kundendaten etc. Die Admin API steuert die administrativen Abläufe und verknüpft beispielsweise Shopware mit ERP-, PIM- oder CRM-Systemen. Die Sync API schließlich ist für Massenoperationen optimiert und erlaubt das sehr schnelle Übertragen von großen Datenmengen, etwa beim Import von Produkten. Alle drei Schnittstellen basieren auf REST, die Store API hält sich zusätzlich an die JSON:API-Konventionen.
Technische Grundlagen und Frameworks
Ein Headless-Frontend für Shopware 6 kann mit fast jeder modernen Technologie umgesetzt werden. Häufig kommen JavaScript-Frameworks zum Einsatz. Auch Shopware selbst hat mit „Shopware Frontends“ ein offizielles Framework auf Basis von Vue 3, Nuxt 3 und TypeScript herausgebracht, dass vorgefertigte Komponenten und Composables zur Anbindung an die Store API zur Verfügung stellt.
Um solche Projekte umzusetzen, greifen viele Unternehmen gern auf eine Shopware Agentur zurück. Die Mischung aus Backend-Konfiguration, API-Design, Frontend-Entwicklung und Performance-Optimierung verlangt doch sehr viel Systemwissen.
Performance und Skalierung im Headless-Setup
Ein oft genanntes Argument für Headless-Architekturen ist die Performance. Frontends, die in Form von statisch generierten Seiten (SSG) oder mit inkrementeller Regeneration (ISR) ausgeliefert werden, erzielen viel bessere Werte bei den Core Web Vitals, also beim Largest Contentful Paint (LCP) oder Cumulative Layout Shift (CLS). Google zieht diese Kennzahlen als Ranking-Signal heran, sodass sich eine schnelle Auslieferung direkt in der Sichtbarkeit niederschlagen kann. Die tatsächliche Leistungsfähigkeit hängt jedoch von vielen Faktoren ab. Die Antwortzeiten der API sollten pro forma bei den typischen Store-API-Requests unter 200 Millisekunden liegen.
Bei komplexen Filteranfragen und beim Ausliefern von personalisierten Inhalten wird dann ein zusätzliches Caching auf Objektebene erforderlich. Redis ist hier häufig das eingesetzte Cache-Backend, sowohl für die Sessions als auch für den HTTP-Cache. Bei internationalen Projekten ist zudem eine geografisch verteilte Auslieferung über ein Content Delivery Network sinnvoll.
Ein realistischer Blick auf die Skalierung zeigt außerdem, dass Headless-Projekte nicht automatisch günstiger sind. Lizenzkosten entfallen zwar, Shopware ist in der Community Edition unter der MIT-Lizenz kostenlos nutzbar. Der Aufwand an Entwicklung, Hosting-Infrastruktur und Monitoring steigt jedoch. Betreiber sollten mit einem höheren initialen Investment rechnen, welches sich dann nur bei entsprechender großer Umsatzgröße oder bei mehreren parallel bedienten Vertriebskanälen amortisiert.
Anbindung an Drittsysteme und Composable Commerce
Das API-first-Prinzip von Shopware 6 zeigt seine Vorteile insbesondere im Bereich von Composable Commerce. Der Shop wird zu einem Baustein in der Gesamtlösung statt ein geschlossenes System zu sein. Payment-Provider wie Mollie, Stripe oder Adyen lassen sich ebenso anbinden wie Versanddienstleister, Steuerdienste, Marketing-Automation-Tools oder Analytics-Tools. Über den Flow Builder lassen sich viele dieser Integrationen ohne Code konfigurieren, für komplexere Szenarien muss allerdings ein eigenes Plugin oder eine App entwickelt werden.
Die Unterscheidung zwischen Plugins und Apps ist hier wichtig. Plugins laufen im selben Prozess wie Shopware selbst und haben tiefen Zugriff auf den Systemkern. Apps kommunizieren nur über Webhooks und die Admin API, was sie sicherer und cloudtauglicher macht. Für die Shopware Cloud sind nur Apps zulässig. Self-hosted Installationen unterstützen beide Erweiterungsformen. Diese klare Trennung ist ein wichtiges Element der langfristigen Produktstrategie und wird die Wahl der Erweiterungsarchitektur maßgeblich beeinflussen.
In größeren Setups wird Shopware im Übrigen häufig nicht als führendes System für Produktdaten eingesetzt. Wohin gehen die Datenströme? Statt in die andere Richtung, fließen die Daten aus einem PIM (Product Information Management) wie Akeneo, Pimcore oder auch Contentserv über die Sync API in den Shop. Bestellungen wiederum landen häufig in einem ERP. Die saubere Definition dieser Datenflüsse zählt zu den wichtigsten Aufgaben in der Projektvorbereitung.
Sicherheit, Wartbarkeit und Compliance
Bei einer API-getriebenen Architektur wandert die Angriffsfläche. Während klassische Shops vor allem Frontend-sicher sein müssen, ist bei Headless-Setups zusätzlich die API- Schicht zu sichern. Rate Limiting, Token-basierte Authentifizierung über OAuth 2.0 und ein durchdachtes Rechtekonzept für die Admin API sind hier Pflichtelemente. Shopware 6 bringt entsprechende Mechanismen mit, ihre richtige Konfiguration ist jedoch Sache des Betreibers.
Datenschutz ist im deutschsprachigen Raum besonders wichtig. Ein Vorteil von Shopware als deutsches Produkt mit der Möglichkeit zur Selbsthosting: Die Daten der Endkunden sind immer in eigener Hand. Für ein DSGVO-konformes Setup sind dann allerdings noch ein paar weitere Einstellungen nötig, wie das richtige Cookie-Consent-Tool, die Anonymisierung der IPs in den Logfiles, das Sichern der Backups etc. Bei Bezahlprozessen ist außerdem die PCI-DSS-Konformität zu beachten, die man erhält, indem man zertifizierte Payment-Provider nutzt und auf die Speicherung von Kartendaten im eigenen System verzichtet.
Die Wartbarkeit eines Headless-Setups hängt stark von der Dokumentation und der Testabdeckung ab. Da Frontend und Backend unabhängig voneinander deployed werden, müssen die API-Verträge klar definiert sein. Contract Testing mit Tools wie Pact und automatisierte End-to-End-Tests mit Cypress oder Playwright haben sich hier in der Praxis bewährt. Durch die semantische Versionierung der APIs lässt sich sicherstellen, dass Änderungen im Backend das Frontend nicht unbemerkt zum Brechen bringen.
Wann der Wechsel auf Headless sinnvoll ist
Nicht für jedes Projekt ist eine Headless-Architektur nötig oder auch nur sinnvoll. Für kleine Shops mit einem Vertriebskanal und geringem Traffic ist der klassische Weg mit Shopware und der mitgelieferten Storefront sicherlich auch wirtschaftlicher. Sobald aber mehrere Frontends bedient werden sollen, sehr individuelle User Experiences gefordert sind oder die Performance-Anforderungen über das hinaus gehen, was mit einem klassischen Setup möglich ist, spielen die Stärken von Headless voll seine Stärken aus.
