commercetools Frontend vs. Alokai vs. FMP: die Composable-Frontend-Optionen

Wenn commercetools euer Backend ist und ihr entscheiden müsst, wie das Frontend entsteht, habt ihr drei echte Optionen, nicht zwei: commercetools Frontend (ehemals Frontastic, das herstellereigene Frontend-Tool), Alokai (ehemals Vue Storefront, ein Vue- und React-basiertes Composable-Frontend-Framework) oder eine gemanagte Frontend Management Platform (FMP), die das Frontend als betriebenen Service behandelt statt als Codebase, die ihr selbst pflegt. Jede Option beantwortet die Frage, wer die Rendering-Schicht besitzt, anders, und genau diese Antwort entscheidet über euer Vue-Storefront-commercetools-Setup für Jahre, nicht für Monate.

Warum commercetools ohne Frontend ausgeliefert wird

commercetools ist API-first und Cloud-nativ konzipiert, GraphQL- und REST-APIs, aber kein Default-Storefront. Genau das ist der Punkt einer Composable-/MACH-Architektur: jede Schicht wird selbst gewählt. Das bedeutet aber, dass jede commercetools-Implementierung mit derselben Frage startet: wer baut und pflegt das Frontend? Der Markt kennt heute drei Antworten, und jede hat einen echten Trade-off.

Option 1: commercetools Frontend (Frontastic)

commercetools hat Frontastic 2021 übernommen und als commercetools Frontend gebrandet, ein JavaScript-basiertes Frontend-Tool, eng an die commercetools-API angebunden. Es liefert vorgefertigte Storefront-Komponenten und Connectoren, was das initiale Setup gegenüber einem Eigenbau von Grund auf verkürzt.

Der Trade-off: es ist ein herstellereigenes Tool innerhalb eines herstellereigenen Backends. Teams, die später das Frontend-Tooling wechseln wollen, Agentur, Marketing-Stack oder Design-System, stecken dann genauso tief in den Konventionen von commercetools Frontend wie zuvor in der API selbst. Composable im Backend, Single-Vendor im Frontend, genau diese Spannung nennen commercetools-Kunden am häufigsten.

Option 2: Alokai (Vue- und React-Storefront-Framework)

Alokai, umbenannt aus Vue Storefront, ist ein Composable-Frontend-Framework, primär rund um Vue.js gebaut, mit React-Unterstützung, gedacht für den Einsatz vor commercetools und anderen MACH-Backends über eine eigene Connector-Bibliothek. Das ist eine legitime Composable-Frontend-Antwort: offene Architektur, aktive Community, kein commercetools-spezifisches Lock-in.

Der Trade-off verschiebt sich, statt zu verschwinden. Alokais Connector-Bibliothek und Hosting-Modell werden zur neuen Abhängigkeit. Wer auf Alokai baut, braucht weiterhin ein dediziertes Frontend-Engineering-Team, das den Storefront baut, pflegt und erweitert, dieselbe Team-Kosten-Frage wie bei jedem Eigenbau, nur mit Alokais Gerüst statt einem leeren Next.js-Projekt.

Option 3: eine gemanagte Frontend Management Platform

Die dritte Option behandelt das Frontend als betriebenen Service. Eine FMP koppelt sich als Standard-Integration an die commercetools-GraphQL-API und liefert Storefront, Editor-Oberfläche und Komponenten-Bibliothek als gemanagte Plattform, nicht als Codebase, die euer Team selbst besitzt und patcht. Marketing-Teams veröffentlichen Seiten über einen visuellen Editor, Engineering konzentriert sich auf Backend-spezifische Logik statt Frontend-Klempnerarbeit, und Multi-Brand- oder Multi-Market-Rollouts laufen auf einer Komponenten-Bibliothek statt auf einem Codebase-Fork pro Marke.

Die drei Optionen im Vergleich

Was das wirklich kostet

Composable Commerce verspricht, dass jede Schicht austauschbar ist. In der Praxis landen die meisten commercetools-Implementierungen composable im Backend und gebunden im Frontend, egal für welche der drei Optionen sie sich entscheiden. Die Zahl, die in Vendor-Vergleichen meist übersprungen wird, ist die Frontend-Team-Kosten: ein dediziertes Frontend-Engineering-Team, egal ob gegen commercetools Frontend, Alokai oder einen Next.js- oder Nuxt-Eigenbau von Grund auf, liegt typischerweise deutlich im sechsstelligen Bereich pro Jahr, sobald ihr Maintenance, On-Call und die Engineering-Zeit für Marketing-Page-Requests mitrechnet.

Diese Kosten sind die eigentliche Entscheidung, mehr als die Framework-Wahl. Wenn euer Team bereits committete Frontend-Engineers hat, die die Codebase selbst besitzen wollen, ist Alokai eine legitime Composable-Frontend-Antwort. Wenn ihr innerhalb des eigenen commercetools-Tooling bleiben und den Trade-off akzeptieren wollt, erledigt commercetools Frontend die Aufgabe. Wenn ihr das Frontend sowohl vom Backend-Hersteller als auch von der Roadmap eines dedizierten Frontend-Teams entkoppeln wollt, ist das der Fall, für den eine gemanagte FMP argumentiert.

Wo Laioutr passt

Laioutrs Agentic Frontend Management Platform koppelt sich über eine Standard-GraphQL-Integration an commercetools, den Headless Frontend für commercetools, und hält das Frontend unabhängig sowohl vom Backend-Hersteller als auch von einer dedizierten Frontend-Codebase. Multi-Brand- und Multi-Market-Rollouts laufen über Composability & Orchestration auf einer Komponenten-Bibliothek statt auf einem Pro-Marke-Fork, genau dort, wo Teams auf commercetools Frontend oder Alokai üblicherweise Arbeit doppelt machen, die sie schon einmal gemacht haben.

Das ist kein Argument gegen commercetools. commercetools verkauft Core Commerce und Produktkatalog inzwischen als eigenständige Module, was die Frontend-Entkopplungsfrage nur noch schärfer macht. Es ist ein Argument dafür, dass die Frontend-Entscheidung dieselbe Sorgfalt verdient wie die Backend-Entscheidung, und dass "composable" für beide Schichten gelten sollte, nicht nur für die, die commercetools kontrolliert. Teams, die sich fragen, wem bei commercetools für Builder die Experience-Schicht gehört, stellen genau diese Frage, nur aus dem API-First-Builder-Blickwinkel statt aus dem Frontend-Tooling-Blickwinkel.

Für einen genaueren Blick, wie Laioutr im Vergleich zu Alokai bei Architektur und Betriebsmodell abschneidet, siehe Laioutr im Vergleich zu Alokai.

FAQ

Ist Alokai dasselbe wie Vue Storefront? Ja, Alokai ist der umbenannte Name für das, was vorher Vue Storefront hieß, ein Composable-Frontend-Framework, primär auf Vue.js gebaut, mit React-Unterstützung.

Müssen wir von commercetools weg migrieren, um eine FMP zu nutzen? Nein. commercetools bleibt bei allen drei hier beschriebenen Optionen das Backend. Die Frontend-Schicht koppelt sich unabhängig von der gewählten Option über die commercetools-Standard-GraphQL-API an.

Welche Option ist am schnellsten live? Eine gemanagte FMP ist für Landingpages und laufendes Marketing-Publishing typischerweise am schnellsten, weil sie über einen visuellen Editor laufen. Das initiale Storefront-Setup ist bei allen drei Optionen auf Ebene des GraphQL-Connectors vergleichbar, der Unterschied zeigt sich bei laufender Pflege und Publishing-Geschwindigkeit.

Können wir später von Frontastic oder Alokai auf eine FMP wechseln, ohne das Backend zu migrieren? Ja. Da alle drei Optionen über dieselbe commercetools-GraphQL-API angebunden sind, erfordert ein Wechsel der Frontend-Schicht kein Anfassen des Backends, nur ein Remapping von Komponenten und Content auf die neue Schicht.

Nächste Schritte

Wenn ihr gerade ein Frontend für commercetools auswählt und wollt, dass das Composable-Versprechen wirklich für beide Schichten gilt, sprecht mit uns darüber, wie eine commercetools-GraphQL-Anbindung über eine gemanagte Frontend-Schicht für euer Team aussieht, oder startet mit der commercetools-Frontend-Seite.

Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr.