Von commercetools Frontend zu backend-agnostisch: Frontend behalten, Stack öffnen

Du hast dich für commercetools entschieden, einen Storefront auf commercetools Frontend gebaut (dem Produkt, das früher Frontastic hieß und heute neben Foundry verkauft wird), und er läuft. Das Problem ist nicht der Storefront. Das Problem ist, woran der Storefront still und leise verdrahtet ist. Wenn dein Frontend innerhalb des Frontend-Produkts eines Anbieters gebaut ist, sind Frontend und Commerce-Backend keine zwei Entscheidungen mehr, sondern eine. In diesem Beitrag geht es darum, wie du den Storefront behältst, den du schon ausgeliefert hast, und das Commerce-Backend wieder zu einer Wahl machst, die du jederzeit neu treffen kannst.

Was "commercetools Frontend" eigentlich koppelt

commercetools Frontend ist eine Frontend-Schicht mit einer Meinung. Sie gibt dir ein Studio zum Komponieren von Seiten, eine Reihe von Daten-Konnektoren und eine Rendering-Runtime. Das ist echt nützlich, und genau hier fängt die Kopplung an. Das Seiten-Kompositions-Modell, die Datenabruf-Schicht und die Deployment-Pipeline sind alle um eine Annahme herum gebaut: Das Commerce-Backend darunter ist commercetools.

Diese Annahme taucht an kleinen, tragenden Stellen auf. Das API-Extension-Modell, die Art, wie Warenkorb- und Checkout-State durch das Frontend fließen, die Form der Produkt- und Kategoriedaten, die deine Komponenten erwarten, das, was das Studio unter einem "Produkt" versteht: alles davon mappt eins zu eins auf die commercetools-API. Nichts davon ist falsch. Es ist nur nicht portabel. Der Storefront, den du gebaut hast, ist ein commercetools-Storefront, kein Storefront, der zufällig heute commercetools nutzt.

Wenn also jemand die berechtigte Frage stellt "Könnten wir einen Teil des Katalogs auf einem anderen Backend fahren oder in zwei Jahren von commercetools weg", lautet die ehrliche Antwort in einem vendor-gekoppelten Frontend: nicht ohne das Frontend neu zu bauen. Die beiden Entscheidungen sind zusammengeschweißt.

Das Lock-in-Risiko eines vendor-gekoppelten Frontends

Lock-in ist kein moralisches Versagen eines Anbieters, sondern eine Eigenschaft einer Architektur. Ein Frontend, das an ein Backend gekoppelt ist, trägt ein paar konkrete Risiken, die man klar benennen sollte.

Der Preishebel wandert zum Anbieter. Wenn der Storefront ohne ein bestimmtes Backend nicht läuft, findet jedes Renewal-Gespräch aus einer schwachen Position statt. Du verhandelst nicht über ein Backend, du verhandelst über die Kosten, dein komplettes Frontend nicht neu zu bauen.

Roadmap-Abhängigkeit. Neues Verhalten im Storefront, ein anderer Checkout-Schritt, eine neue Merchandising-Regel, eine Änderung daran, wie Bundles rendern, wartet oft darauf, was das Frontend-Produkt bereitstellt. Du bewegst dich im Release-Takt des Anbieters, nicht in deinem.

Ein einzelner architektonischer Single Point of Failure. Wenn das Backend an ein Skalierungslimit stößt, seine Preise ändert oder einen strategischen Schwenk macht, den du nicht mitgehen willst, erbst du das, weil es keine Naht gibt, um es zu tauschen. Eine Best-of-Breed-Wahl für Suche, Payments oder Fulfilment lässt sich leicht zurücknehmen. Ein ans Frontend geschweißtes Backend nicht.

Team-Wissen bündelt sich auf den Anbieter, nicht auf dein Produkt. Jede Stunde, die ins spezifische Extension-Modell eines Frontend-Produkts fließt, ist eine Stunde, die nicht in portable Frontend-Fähigkeiten fließt. Bei enger Kopplung ist die Expertise deines Teams ein Asset, das sich nur auszahlt, solange du bleibst.

Nichts davon heißt, dass commercetools das falsche Backend ist. Für viele Teams ist es das richtige. Es heißt, dass die Kopplung die Belastung ist, nicht der Anbieter.

Der Entkopplungspfad: Storefront behalten, Backend öffnen

Die gute Nachricht: Entkoppeln ist kein Rebuild. Der Storefront, den du ausgeliefert hast, die Komponenten, das Design-System, die Seitenstrukturen, ist der Teil, der es wert ist, behalten zu werden. Was sich ändert, ist die Schicht darunter. Der Pfad hat drei praktische Schritte.

1. Einen Datenvertrag zwischen Frontend und Backend legen

Heute sprechen deine Komponenten mit ziemlicher Sicherheit direkt commercetools, oder über die Konnektoren des Frontend-Produkts, was eine Schicht tiefer dasselbe ist. Der erste Schritt ist, einen stabilen, backend-neutralen Vertrag darüber zu definieren, was das Frontend braucht: eine Produkt-Form, eine Warenkorb-Form, einen Checkout-Flow, ein Kunden-Objekt. Deine Komponenten rendern gegen diesen Vertrag. Ein dünner Adapter mappt den Vertrag auf commercetools. Die commercetools-Spezifika liegen jetzt an einer Stelle, statt über jede Komponente verstreut zu sein.

2. Die Seiten-Komposition aus dem Studio des Anbieters herauslösen

Der zweite Schritt ist, die Kompositions-Schicht zu besitzen, den Teil, der entscheidet, welche Sections auf welcher Seite mit welchen Daten erscheinen. In einem vendor-gekoppelten Setup liegt das im Frontend-Produkt und setzt das Backend des Anbieters voraus. Sie in ein Composable Headless Frontend zu verlagern, das du kontrollierst, heißt, dass die Seitenstruktur einen Backend-Wechsel unangetastet übersteht, weil sie gegen den Datenvertrag komponiert, nicht direkt gegen commercetools.

3. Das Backend zu einem Konnektor machen, nicht zu einem Fundament

Sobald der Vertrag und die Kompositions-Schicht dir gehören, wird das Commerce-Backend zu einem Konnektor hinter dem Adapter. commercetools bleibt, wenn es dir gute Dienste leistet. Es kann auch neben einem anderen Backend für einen bestimmten Katalog, eine Region oder eine Business-Unit stehen oder später komplett ersetzt werden, ohne dass das Frontend es merkt. Der Storefront weiß nicht mehr und interessiert sich nicht mehr dafür, welches Backend die Query beantwortet hat.

Das ist dasselbe Composable-Storefront-Prinzip, das schon auf Suche, Payments und Order Management angewendet wird: Das Spezialsystem behält die Fachlogik, das Frontend besitzt die Oberfläche und bleibt darunter austauschbar.

Backend-agnostisch vs. vendor-gekoppeltes Frontend

• Dimension | Vendor-gekoppeltes Frontend | Backend-agnostisches Frontend
• Backend-Wahl | Fest an einen Anbieter gebunden | Austauschbar hinter einem Adapter
• Storefront bei Backend-Wechsel | Rebuild | Bleibt, nur der Adapter ändert sich
• Multi-Backend (Region, Business-Unit) | Selten machbar | Über einen Datenvertrag unterstützt
• Roadmap für neues UI-Verhalten | Wartet auf das Frontend-Produkt | Frontend-Team liefert direkt
• Renewal-Hebel | Niedrig, Alternative ist Rebuild | Höher, Backend ist ein ersetzbares Teil
• Team-Fähigkeiten | An das Modell eines Anbieters gebunden | Portable Frontend- und Vertrags-Skills

FAQ

Müssen wir commercetools verlassen, um backend-agnostisch zu werden? Nein, und genau das ist der Punkt. Backend-agnostisch heißt, dass commercetools eine Wahl ist, die du weiter triffst, weil sie funktioniert, keine Abhängigkeit, aus der du nicht raus kannst. Die meisten Teams entkoppeln zuerst und lassen commercetools noch lange hinter dem Adapter laufen.

Heißt Entkoppeln, den Storefront wegzuwerfen, den wir gebaut haben? Nein. Der Storefront ist das Asset, das du behältst. Entkoppeln ändert die Schicht darunter: den Datenvertrag, die Kompositions-Schicht und den Backend-Konnektor. Die Komponenten und das Design-System bleiben.

Ist ein Adapter nicht einfach mehr Code zum Pflegen? Es ist ein Adapter statt commercetools-Annahmen, die über jede Komponente verstreut sind. Das ist meist weniger zu pflegen, und es ist die Naht, die jede künftige Backend-Entscheidung günstig statt katastrophal macht.

Wie lange dauert das? Es ist inkrementell, kein Big-Bang-Cutover. Du kannst den Datenvertrag Seitentyp für Seitentyp einführen und den vendor-gekoppelten und den entkoppelten Pfad während des Übergangs parallel fahren.

Was, wenn wir mit commercetools zufrieden sind? Dann zahlt sich Entkoppeln trotzdem aus, weil es eine harte Abhängigkeit in eine weiche verwandelt. Gehen zu können ist das, was eine gute Beziehung gut hält.

Der Zielzustand: eine backend-agnostische Frontend-Schicht

Der Endpunkt dieses Pfades ist ein Frontend, das eine eigenständige Schicht ist, kein Anhängsel des Backends. Diese Schicht besitzt Seiten-Komposition, Datenvertrag und Rendering und behandelt jedes Backend, Commerce, Suche, Content, als Konnektor hinter einer stabilen Schnittstelle. Genau das ist eine Frontend Management Platform: der Ort, an dem der Storefront unabhängig von einem einzelnen Backend lebt, gemanagt als eigenes Produkt mit eigenem Release-Takt.

Laioutr baut diese Schicht. Dein Team komponiert weiter in einem Studio, der Unterschied ist, dass das Studio gegen einen backend-neutralen Vertrag komponiert. So läuft der Storefront, den du auf commercetools gebaut hast, weiter, während das Backend darunter zu einer Entscheidung wird, die du neu treffen kannst, wann immer es sinnvoll ist. Der nächste Schritt ist, dass Routine-Änderungen an dieser Schicht von einer Agentic Frontend Management Platform übernommen werden, damit das Frontend-Team seine Zeit auf die Oberfläche verwendet, nicht auf die Verrohrung.

Nächster Schritt

Läufst du auf commercetools Frontend und fragst dich, was es bräuchte, um den Storefront zu behalten und das Backend zu öffnen? Sprich mit dem Laioutr-Team und wir mappen dein aktuelles Setup auf ein backend-agnostisches Frontend, mit commercetools weiterhin an Bord, bis du dich anders entscheidest.