commercetools + Akeneo: das perfekte Match fürs Frontend
commercetools + Akeneo: das perfekte Match fürs Frontend
commercetools und Akeneo sind ein starkes Composable-Duo: commercetools liefert die Commerce-Logik, Akeneo die saubere Single Source of Truth für Produktdaten. Der Haken ist, dass beide Systeme headless sind und kein Frontend mitliefern. Ob das Match wirklich funktioniert, entscheidet sich also nicht im Backend, sondern in der Storefront, in der beide Datenquellen zusammenlaufen.
Was ist das commercetools-Akeneo-Setup?
Die Aufgabenteilung ist klar. Akeneo ist das PIM (Product Information Management): dort pflegst Du Attribute, Varianten, Übersetzungen, Media-Assets und die Anreicherung, die aus einem Rohdatensatz eine verkaufsfähige Produktbeschreibung macht. commercetools ist die Composable-Commerce-Plattform: Katalog-Struktur, Preise, Bestand, Warenkorb, Checkout, Promotions, alles über GraphQL- und REST-APIs.
In der Praxis fließen Akeneo-Produktdaten über einen Connector oder Middleware nach commercetools, wo sie als Produkte, Product Types und Custom Fields liegen. Manche Teams spielen angereicherte Attribute direkt aus Akeneo an die Storefront aus und halten commercetools schlank auf Commerce-Kerndaten. Beide Muster sind gängig. Und beide erzeugen dieselbe offene Frage: Wer setzt diese verteilten Daten am Ende in eine schnelle, konsistente Oberfläche um?
Das Problem, das viele aktuell haben
Der Composable-Promise lautet: Tausche jede Komponente aus, ohne den Rest anzufassen. Im Backend hält das Versprechen. commercetools und Akeneo sind beide API-first, beide ersetzbar, beide EU-hostbar. Der Bruch kommt eine Ebene höher.
Denn weder commercetools noch Akeneo liefern ein Default-Frontend. Du hast drei Optionen, und jede hat einen Preis:
- Eigenbau mit Next.js oder Nuxt plus manuellen Connectoren zu beiden Systemen. Das kostet typisch sechsstellig in der Implementierung und bindet ein dauerhaftes Frontend-Team.
- commercetools Frontend (vormals Frontastic) als vendor-eigener Layer. Löst das Frontend-Problem, erzeugt aber neues Lock-in an einen einzelnen Anbieter.
- Drittanbieter-Composable-Frontend, das pro Tool wieder eigene Bindung und Custom-Glue produziert.
Das eigentliche Reibungsproblem sitzt genau an der Naht: Akeneos reicher Attribut-Baum und commercetools' Commerce-Objekte müssen in der Storefront zusammengeführt werden, in mehreren Sprachen, über mehrere Marken, ohne dass die Core Web Vitals leiden. Wenn diese Naht schlecht gebaut ist, sieht der Kunde veraltete Attribute, fehlende Übersetzungen oder eine Detailseite, die drei Sekunden auf Daten wartet. Wir haben dieses Muster schon in einem anderen Stack beschrieben, nämlich warum der Frontend-Layer bei Akeneo und Magento der eigentliche Flaschenhals ist. Die Diagnose bleibt gleich, egal ob das Backend Magento oder commercetools heißt.
Wie Laioutr das Match einlöst
Laioutr ist eine Frontend Management Platform (FMP): die Frontend-Steuerungsebene, die sich an Deine bestehenden Backends koppelt, statt sie zu ersetzen. Für das commercetools-Akeneo-Setup heißt das konkret drei Dinge.
Standard-Anbindung statt Custom-Glue. Laioutr spricht direkt mit der commercetools-GraphQL-API und bindet Akeneo-Attribute über die Orchestrierungsebene ein. Die Produktdaten aus beiden Quellen werden zur Render-Zeit aufgelöst und in eine konsistente Komponenten-Struktur gemappt, ohne dass Dein Team pro Attribut einen eigenen Fetch schreibt.
Ein Frontend für beide Datenwelten. Eine Produktdetailseite zieht Preise und Verfügbarkeit aus commercetools und den angereicherten Content aus Akeneo in dieselben Komponenten. Multi-Brand und Multi-Locale laufen auf einer UI-Library, sodass eine neue Marke oder Sprache keine neue Codebasis braucht.
Marketing baut, Engineering definiert. Im Studio-Editor komponieren Deine Product- und Marketing-Owner Seiten aus den Komponenten, die Deine Entwickler einmal definiert haben. Eine neue Landingpage entsteht in Stunden statt im Engineering-Sprint. Das entkoppelt die beiden Teams, die sich sonst gegenseitig blockieren.
Für Entwickler: Die Anbindung läuft über die GraphQL-API von commercetools und die Content-Delivery von Akeneo, Edge-Caching sorgt für niedrige LCP-Werte auch bei großen Katalogen. Deine Composable-Architektur bleibt intakt, das Frontend wird austauschbar statt zum vierten Lock-in.
Was Du gewinnst
- Dimension | Vorher (Eigenbau / Frontastic) | Mit Laioutr-FMP
- Zeit | Frontend-Aufbau über Monate, jede Landingpage ein Sprint | Composable-Launch in Wochen, Landingpages in Stunden
- Geld | Frontend-Team ab sechsstellig pro Jahr plus Lizenz-Lock-in | FMP als Managed Service, Engineering fokussiert auf Backend-Logik
- Qualität | Naht-Bugs zwischen PIM und Commerce, wackelige Core Web Vitals | Konsistente Daten aus beiden Quellen, Edge-Caching, WCAG- und DSGVO-konform
FAQ
Muss ich Akeneo oder commercetools austauschen, um Laioutr zu nutzen? Nein. Laioutr setzt sich als Frontend-Ebene auf Deine bestehende Architektur. Beide Backends bleiben, wo sie sind.
Wie werden Akeneo-Attribute in der Storefront konsistent gehalten? Über die Orchestrierungsebene, die Produktdaten aus commercetools und Akeneo zur Render-Zeit auflöst und in dieselben Komponenten mappt. Änderungen im PIM erscheinen ohne separaten Frontend-Deploy.
Was kostet das? Die Tarife findest Du unter laioutr.com/pricing. Der relevante Vergleich ist die Total-Cost eines dedizierten Frontend-Teams gegenüber einem Managed-Service-Layer.
Wie lange dauert die Umsetzung? Ein Single-Brand-Setup ist mit Founder-Begleitung typisch in unter zwei Wochen live, Multi-Brand-Enterprise-Setups je nach Datenkomplexität in acht bis vierzehn Wochen.
Nächste Schritte
Wenn commercetools und Akeneo Deine Backend-Entscheidung sind, ist das Frontend die letzte offene Frage. Buch Dir eine Live-Demo und wir zeigen Dir die Anbindung an einem echten Katalog.
Weitere Themen aus der Laioutr-Plattform
Über den Autor: Sebastian Langer ist Co-Founder von Laioutr und arbeitet mit Enterprise-Teams an Composable-Frontend-Architekturen für commercetools, Akeneo und weitere headless Backends.