TL;DR. Headless vs Monolith ist kein Religionskrieg, sondern eine Architekturentscheidung. Headless vs Monolith heißt: Volle Frontend-Freiheit gegen schnellere Time-to-Market. Wir zeigen, wann Headless vs Monolith klar zugunsten von Headless kippt und wann der Monolith der pragmatischere Weg bleibt.
Die Frage "Headless oder Monolith?" ist so beliebt wie falsch gestellt. Weil es keine universelle Antwort gibt. Es gibt nur: Was brauchst du tatsächlich. Shopware ist monolithisch, Commercetools ist headless, und beide sind auf High-Level großartig. Wir bauen mit beiden seit Jahren und sagen dir welche Architektur für dich passt.
Inhalt
- Was bedeutet Headless?
- Was bedeutet Monolith?
- Der Vergleich: Feature für Feature
- Wann brauchst du Headless?
- Monolith ist nicht out
- Die versteckte Komplexität
- Fazit
Was bedeutet Headless?
Headless bedeutet: Backend und Frontend sind entkoppelt. Das Backend ist nur API. Es weiß nicht wie das Frontend aussieht.
Real-Beispiel: Mit Commercetools oder Shopware Headless brauchst du:
- Ein Commerce API Backend (Shopware, Commercetools, SAP Commerce Cloud)
- Ein separates Frontend (Nuxt, Next.js, Vue, React)
- Eine Datenschicht dazwischen (GraphQL oder REST API)
Der Vorteil: Backend und Frontend entwickeln unabhängig. Backend-Updates beeinflussen Frontend nicht. Frontend-Redesign braucht kein Backend-Redeployment.
Der Nachteil: Zwei Systeme zu bauen, zu hosten und zu warten. Komplexität.
Was bedeutet Monolith?
Monolith bedeutet: Backend und Frontend sind gekoppelt. Frontend ist Teil der Commerce-Plattform.
Shopware mit Theme ist monolithisch. Das Theme ist fest an Shopware gebunden. Shopware-Update = Theme-Update.
Der Vorteil: Ein System, ein Deployment, eine Datenbank. Einfacher. Schneller.
Der Nachteil: Updates erzwingen oft auch Frontend-Anpassungen. Und: Skalierungsgrenzen.
Der Vergleich: Feature für Feature
| Feature | Headless | Monolith (Shopware) |
|---|---|---|
| Deployment | 2 Systeme, komplexer | 1 System, einfach |
| Update-Zyklus | Frontend + Backend separat | Gekoppelt |
| Multi-Channel | Native (1 API für alle) | Schwieriger (Duplicate Code) |
| Time-to-Market | Langsamer (2 Teams) | Schneller (1 Team) |
| Hosting-Kosten | Höher (2 Systeme) | Niedriger (1 System) |
| Skalierbarkeit | Unbegrenzt | Begrenzt (ab ~1M EUR/Jahr) |
| Framework-Freiheit | Ja (Nuxt, Next, Vue, React) | Nein (an Shopware-Theme gebunden) |
| Performance | Optimierbar (Frontend lädt schnell) | Abhängig vom Theme |
| Learning-Curve | Hoch | Mittel |
Die Tabelle zeigt: Keine Lösung gewinnt überall.
Wann brauchst du Headless?
Die Frage ist nicht "Ist Headless modern?" sondern "Reicht der Standard oder brauch ich spezialisiert?"
Headless ist richtig wenn:
- Mehr als 30% deiner Frontend-Anforderungen sind Custom. Das ist die Schwelle. Ein gutes Theme kann bis 30% Custom verkraften, dann wird es ineffizient.
- Du mehrere Clients brauchst. Web, Mobile App, Kiosk-Display, etc. Ein API, mehrere Konsumenten. Mit Monolith Code-Duplication.
- Langfristige Investition (5+ Jahre) wo TCO-Ersparnis durch weniger Theme-Updates relevant wird.
- Dein Team groß genug ist (6+ Developer) dass die Frontend/Backend-Trennung Sinn macht.
Ein Beispiel: ARMEDANGELS brauchte Web, Mobile App und B2B Portal. Mit Monolith: 3x Code (eine API, 3 Implementierungen). Mit Headless: saubere Separation.
Monolith ist nicht out
Jeder Headless-Evangelist tut so als wäre Monolith überholt. Das ist falsch.
Shopware Monolith ist immer noch die richtige Wahl für:
- B2C Shops unter 2M EUR/Jahr Umsatz
- Teams mit 1 bis 3 Developern
- Shops wo das Frontend sich kaum ändert
- Projekte mit Budget unter 100.000 EUR
- Alle die einfach einen Shop brauchten, nicht spezialisieren
Shopware mit Theme: 2 bis 3 Monate zum Live. Headless: 5 bis 7 Monate. Das zählt.
Die 30%-Regel:
- Unter 30% Custom: Monolith ist schneller und günstiger
- Über 30% Custom: Deine Architektur muss sich ändern. Das kann Headless sein (wenn Custom im Frontend) oder Microservices daneben (wenn Custom im Backend). Aber die Plattform (Shopware) bleibt oft die gleiche.
Das ist wichtig zu verstehen: Headless ist nicht "bessere Plattform", es ist "spezialisierte Architektur für spezialisierte Anforderungen".
Die versteckte Komplexität
Headless ist nicht nur technisch komplexer. Es ist auch operativ komplexer.
Was dich überraschen wird:
- API-Versionierung: Dein Frontend braucht immer noch API-Docs. Wenn du die API änderst, bricht das Frontend. Das ist das gleiche Coupling, nur sichtbarer.
- GraphQL vs REST: Beide haben Vor- und Nachteile. GraphQL ist flexibler, REST ist einfacher.
- Caching: Mit Headless musst du verstehen wie HTTP-Caching, CDN-Caching und Application-Caching zusammenwirken.
- Deployment synchronisieren: Backend und Frontend müssen manchmal zeitgleich deployen. Das ist ein Koordinations-Problem.
Real-Talk: Etwa 30% der Headless-Projekte werden überkompliziert weil die Teams das nicht antizipiert haben. In unseren Projekten bereiten wir Kunden explizit auf diese operativen Hürden vor. Das spart später viel Nerven.
Fazit
Headless vs Monolith ist eine Frage der Architekturreife, nicht der Mode. Headless ist nicht "besser", Monolith ist nicht "veraltet". Es ist eine Architekturbewusstsein.
Wenn du einen Shop für 50.000 EUR mit 2 Entwicklern bauen willst, nimm Shopware Monolith. 3 Monate, gut. Was ein Headless-Projekt konkret kostet, zeigt unser Artikel zu den Headless Commerce Kosten.
Wenn du einen internationalen Multi-Channel-Shop mit Wachstumsplänen aufbaust, nimm Headless. 4 Monate, aber gebaut für die Zukunft.
Wir beraten beide Richtungen ehrlich. Headless ist nicht für jeden, aber für die richtige Use-Case erspart dir Jahre Ärger.