Shopify and Vercel are rebuilding Hydrogen as an open, runtime-agnostic foundation. Hydrogen now dep…
Headless Frontend für Spryker: FMP oder Eigenbau?
Headless Frontend für Spryker: Wann ein FMP vor dem Enterprise-Backend die richtige Entscheidung ist
Spryker ist als Composable-Backend gebaut, nicht als fertige Storefront. Wer Spryker einführt, steht deshalb früh vor einer Frontend-Entscheidung: die Storefront gegen die Glue-API komplett selbst bauen und über Jahre pflegen, oder eine Frontend Management Platform (FMP) davor setzen und die Präsentationsebene als Produkt betreiben. Dieser Beitrag ist der Entscheidungs-Begleiter zu genau dieser Frage, keine Glue-API-Anleitung.
Der Term Frontend Management Platform (FMP) stammt von Laioutr und beschreibt die Kategorie: die Steuerungsebene fürs Commerce-Frontend, die zwischen Backend und Storefront sitzt. Für ein Enterprise-Team, das mit Spryker plant, ist die relevante Frage nicht "headless ja oder nein", sondern "bauen wir die Frontend-Ebene selbst oder kaufen wir sie als Plattform ein".
Was ein FMP vor Spryker konkret ist
Spryker liefert die Commerce-Logik und die Glue-API. Was es bewusst offen lässt, ist die eigentliche Storefront: das Rendering, die Komponenten, die Editier-Oberfläche fürs Marketing, das Hosting der Präsentationsebene. Genau diese Lücke schließt ein FMP.
Eine FMP setzt sich als eigene Ebene auf die Glue-API und übernimmt vier Dinge, die Du sonst selbst bauen und betreiben müsstest:
- Datenanbindung über eine einheitliche Schicht statt handgeschriebenem Glue-Code pro Endpunkt. Bei Laioutr ist das der Orchestr-Layer, der Produkt-, Bestand- und Bestelldaten in ein einheitliches Frontend-Schema normalisiert.
- Komponenten-Ebene aus einer zentralen, geprüften UI-Library statt eines projektspezifischen Design-Systems, das ein Team von Grund auf pflegt.
- Editier-Oberfläche für Marketing und Redaktion, damit Landingpages und Kampagnen ohne Engineering-Ticket live gehen.
- Betrieb der Präsentationsebene inklusive Hosting, CI/CD, Performance-Monitoring und Security als Plattform-Leistung.
Kurz: Spryker bleibt die Engine, die FMP ist die Frontend-Ebene darüber. Die Backend-Investition in Spryker bleibt unangetastet.
Das Problem, das Enterprise-Teams mit dem Eigenbau haben
Der Standardweg ist, die Composable Storefront selbst zu bauen. Das funktioniert, hat aber einen Preis, der erst im Betrieb sichtbar wird. Ich sehe bei Enterprise-Setups regelmäßig drei Muster:
Die Storefront wird zum Dauer-Projekt. Der Erst-Build ist planbar. Was danach kommt, ist es selten: Framework-Upgrades, Core-Web-Vitals-Regressionen nach Releases, Accessibility-Nachrüstung, jedes neue Feature als Frontend-Ticket. Die Storefront, die als einmaliges Projekt kalkuliert war, wird ein permanenter Team-Posten.
Marketing hängt an Engineering. Jede Kampagnen-Seite, jeder saisonale Aufsatz, jede Banner-Änderung läuft über einen Sprint. In einem B2B-Setup mit mehreren Marken oder Märkten multipliziert sich das, weil jede Variante denselben Pfad nimmt.
Frontend-Qualität ist eine Team-Aufgabe, keine Eigenschaft. Performance, WCAG-Konformität und Brand-Konsistenz über alle Devices sind bei einem Eigenbau genau so gut, wie das Team sie laufend hält. In der Praxis wird Qualität zur Restgröße am Quartalsende, nicht zum Default.
Wer diese drei Muster über zwei bis drei Jahre hochrechnet, sieht: Die eigentliche Kostenfrage ist nicht der Erst-Build, sondern der Unterhalt. Genau hier verschiebt sich die Entscheidung. Welche Alternativen es gibt, geht die Spryker-Frontend-Alternative im Detail durch.
Die Entscheidung: FMP oder Eigenbau
Es gibt keinen Default. Es gibt eine ehrliche Einschätzung, wo Dein Team steht. Diese Kriterien helfen bei der Richtung.
Eine FMP ist die bessere Wahl, wenn:
- Deine Storefront-Anforderung Standard-Commerce ist (PLP, PDP, Checkout, Content-Seiten, B2B-Flows) und nicht ein hochgradig singuläres Interface, das es so nirgends gibt.
- Marketing-Geschwindigkeit ein echter Engpass ist und Landingpages heute im Sprint-Stau hängen.
- Frontend-Qualität (Performance, BFSG-Konformität, Brand-Konsistenz) verbindlich sein muss und nicht vom aktuellen Team-Kalender abhängen darf.
- Du Multi-Brand oder Multi-Market betreibst und Theme-Forks pro Markt vermeiden willst.
- Dein Engineering-Team seine Kapazität lieber in Backend-Logik, Integrationen und Custom-Features steckt als in Storefront-Wartung.
Der Eigenbau bleibt sinnvoll, wenn:
- Die Storefront ein strategisch einzigartiges Interface ist, dessen Kern-Interaktion Dein Wettbewerbsvorteil ist.
- Du ein dediziertes Frontend-Team hast, das die Storefront ohnehin dauerhaft ownen soll und kann.
- Sehr spezifische Anforderungen bestehen, die eine Plattform-Komponenten-Ebene nicht abbildet und die kein Standard-Pattern sind.
Der Kern der Entscheidung ist eine Kapazitätsfrage, keine Technikfrage. Beide Wege liefern eine funktionierende Storefront gegen die Glue-API. Der Unterschied liegt darin, wer die Präsentationsebene über Jahre trägt. Die teamnahe Version dieser Abwägung nimmt Composable Storefront vs. Laioutr für Spryker auseinander.
Was Du mit einer FMP gewinnst
| Dimension | Eigenbau der Composable Storefront | Mit Laioutr als FMP |
|---|---|---|
| Time-to-Market | Neue Seiten als Frontend-Ticket im Sprint | Landingpages direkt im Studio-Editor, ohne PR-Review |
| Betrieb | Framework-Upgrades, Hosting, CI/CD im eigenen Team | Managed als Plattform-Leistung, EU-gehostet |
| Qualität | Performance und Accessibility als laufende Team-Aufgabe | Core Web Vitals und WCAG-3.0-Basis ab Werk |
| Datenanbindung | Glue-Integration pro Feature selbst geschrieben | Einheitlicher Datenlayer über Orchestr |
Der Punkt ist nicht, dass ein Eigenbau schlecht wäre. Der Punkt ist, dass eine FMP die Storefront von einem Dauer-Projekt in eine Plattform-Eigenschaft verwandelt. Marketing bekommt Kontrolle, Engineering bekommt Kapazität zurück, und die Backend-Entscheidung für Spryker bleibt reversibel: Laioutr sitzt als Composable Headless Frontend auf über 50 Backends, Spryker ist eines davon.
FAQ
Ersetzt eine FMP die Glue-API oder Spryker selbst? Nein. Spryker bleibt die Commerce-Engine, die Glue-API bleibt der Zugang zu den Daten. Die FMP ist die Ebene darüber, die aus diesen Daten die Storefront macht.
Verlieren wir Flexibilität gegenüber einem Eigenbau? Die Komponenten-Ebene ist gestaltbar und das Code-Layer bleibt zugänglich. Was wegfällt, ist der Unterhalt der Grundinfrastruktur, nicht die Kontrolle über das Erscheinungsbild.
Was, wenn wir Spryker später ablösen? Weil das Frontend über einen einheitlichen Datenlayer an das Backend gebunden ist, kostet ein späterer Backend-Wechsel einen Connector statt einen kompletten Frontend-Rewrite. Das ist der Kern der Decoupling-Idee: Backend austauschbar, Frontend stabil.
Für wen lohnt sich die FMP-Route nicht? Für Teams mit einem strategisch einzigartigen Interface als Wettbewerbsvorteil und einem dedizierten Frontend-Team, das die Storefront ohnehin dauerhaft ownen will.
Nächste Schritte
Wenn Deine Storefront-Anforderung im Standard-Commerce liegt und Marketing-Speed plus Frontend-Qualität verbindlich sein müssen, ist die FMP-Route vor Spryker die naheliegende. Wenn Du ein singuläres Interface baust und das Frontend-Team ohnehin dediziert ist, bleib beim Eigenbau. Beide Entscheidungen sind vertretbar, solange sie aus der Kapazitätsfrage kommen und nicht aus dem Reflex.
Wie die Frontend-Ebene für Spryker konkret aussieht, zeigt die Seite zum Headless Frontend für Spryker. Wenn Du wissen willst, wie die Agenten-Ebene darüber Content, SEO und Performance automatisiert, wirf einen Blick auf die Agentic Frontend Management Platform.
Weitere Themen aus der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr. Er arbeitet mit Enterprise- und B2B-Teams an der Frage, wie sich die Frontend-Ebene modernisieren lässt, ohne das Backend anzufassen.