BigCommerce Catalyst und Makeswift gegen ein backend-agnostisches Frontend

BigCommerce hat seine Storefront-Story in den letzten zwei Jahren neu aufgestellt. Catalyst ist das neue Storefront-Framework, eine Basis auf Next.js und React, die mit der BigCommerce Storefront GraphQL API spricht. Makeswift, der Visual Editor, den BigCommerce 2024 gekauft hat, sitzt obendrauf als die Ebene, in der Marketing Seiten ohne Developer-Ticket bearbeitet. Zusammen ersetzen sie den älteren Stencil-Theme-Ansatz durch etwas, das viel eher nach modernem Composable Commerce aussieht. Für ein Team, das ohnehin auf BigCommerce als Backend setzt, ist das ein echter Fortschritt. Die Entscheidung, für die es sich zu bremsen lohnt, ist eine andere: Beide Tools sind gebaut, um mit dem BigCommerce-Backend zu arbeiten, und nur mit diesem Backend. Dieser Artikel schaut, was diese Kopplung bedeutet und wann ein backend-agnostisches Frontend die bessere Wahl ist.

Was Catalyst und Makeswift wirklich sind

Catalyst ist das Storefront-Framework von BigCommerce. Es kommt als Next.js-Anwendung (React), verdrahtet mit der Storefront GraphQL API, mit einer Component-Library und einer lauffähigen Referenz-Storefront ab Werk. Es ist der moderne Nachfolger von Stencil, dem älteren, Handlebars-basierten Theme-Framework von BigCommerce, und der Weg, auf den BigCommerce Teams heute für Headless- und Composable-Storefronts lenkt.

Makeswift ist ein Visual Page Builder. BigCommerce hat ihn 2024 übernommen und als visuelle Editier-Ebene für Catalyst positioniert: Marketing komponiert und bearbeitet Seiten, die aus React-Components bestehen, ohne Code anzufassen, während Developer die Kontrolle über die Components darunter behalten. Wer die Kategorie verfolgt, kennt das Muster. Es ist dieselbe Trennung zwischen Developer-eigenen Components und Marketer-eigener Komposition, die eine Frontend Management Platform ausmacht.

Beide sind solide. Catalyst ist eine echte Verbesserung gegenüber handgepflegten Stencil-Themes, und Makeswift schließt die Visual-Editing-Lücke, die Headless-Setups normalerweise aufreißen. Die Frage ist nicht die Qualität. Es ist die Kopplung.

Die Kopplungs-Frage

Catalyst liest seine Daten aus der BigCommerce Storefront GraphQL API. Makeswift bearbeitet Seiten im selben Kontext. Das ist so gewollt, und für ein auf BigCommerce festgelegtes Team ist es genau das, was du willst: enge Integration, ein Anbieter, ein supporteter Pfad. Der Kompromiss ist, dass das Frontend, das du baust, ein BigCommerce-Frontend ist. Wenn sich das Backend-Bild später ändert, eine Tochtermarke auf einer anderen Plattform, eine B2B-Einheit, die commercetools braucht, oder die Entscheidung, ganz von BigCommerce wegzugehen, kommt die Catalyst-Storefront nicht mit. Du baust das Frontend gegen das neue Backend neu.

Ein backend-agnostisches Frontend dreht dieses Verhältnis um. Statt dass die Storefront direkt aus der API eines Backends liest, sitzt eine Frontend Management Platform als eigene Ebene und verbindet sich mit dem Backend über einen Daten-Layer, der Produkt-, Preis-, Bestands- und Bestelldaten in ein einziges Component-Schema normalisiert. BigCommerce kann heute dahinterliegen. Ein anderes Backend kann in zwei Jahren dahinterliegen, ohne die Storefront neu zu bauen. Die breitere Auswahl haben wir in BigCommerce Headless-Frontend-Optionen im Vergleich gegenübergestellt. Dieser Beitrag geht gezielt um den Catalyst- und Makeswift-Pfad gegenüber dieser agnostischen Ebene.

Catalyst plus Makeswift gegen ein backend-agnostisches Frontend

Wann Catalyst plus Makeswift die richtige Wahl ist

Wenn BigCommerce dein Backend ist und du keinen realistischen Plan hast, das zu ändern, ist Catalyst plus Makeswift eine vernünftige, gut supportete Wahl. Du bekommst First-Party-Integration, ein vom Anbieter gepflegtes Framework und einen dafür gebauten Visual Editor. Ein fähiges React-Team, das den Storefront-Code direkt besitzen will und mit dem Nachziehen von Catalyst- und Next.js-Upgrades umgehen kann, ist schnell produktiv. Die Kopplung an BigCommerce ist nur dann ein Kostenpunkt, wenn sich dein Backend ändern könnte. Wenn nicht, ist sie einfach die Form der Plattform, die du gewählt hast.

Wann ein backend-agnostisches Frontend mehr Sinn ergibt

Die agnostische Ebene verdient ihren Platz, wenn das Backend keine abgeschlossene Frage ist. Typische Signale: Du betreibst mehr als ein Commerce-Backend über Marken oder Regionen, du prüfst einen Backend-Wechsel, willst aber das Frontend nicht als Teil davon neu bauen, oder du willst die Architektur-Entscheidung reversibel halten. Das ist derselbe Grund, aus dem Teams Frontend-Modernisierung von Backend-Replatforming entkoppeln, mehr dazu in BigCommerce Replatforming ohne Frontend-Neubau und in Alternativen zu BigCommerce. Mit einem Composable Headless Frontend, ausgeliefert als managed Frontend as a Service, sind Framework-Upgrades, Hosting und Security-Patches Plattform-Arbeit statt Sprint-Arbeit deines Teams, und dieselbe Storefront läuft über dem Backend, das du jeweils anschließt.

Für Engineering-Teams sitzt der praktische Unterschied an einer Stelle: dort, wo das Backend benannt wird.

# Catalyst: Components lesen direkt die BigCommerce Storefront API
product = bigcommerce.storefront.query(productId)

# Backend-agnostisch: Components lesen ein normalisiertes Schema,
# das Backend wird im Daten-Layer aufgelöst
product = orchestr.resolve("Product", productId)   # BigCommerce heute, später ein anderes Backend

Die Component, die eine Produktdetailseite rendert, ändert sich nicht, wenn sich das Backend ändert. Nur der Resolver hinter dem Schema tut es.

Migrationspfade: Stencil zu Catalyst oder Stencil zu einem managed Frontend

Teams auf älteren Stencil-Themes stehen direkt vor dieser Gabelung. Die Migration von Stencil zu Catalyst hält dich innerhalb von BigCommerce und bringt dich auf ein modernes React-Framework, das du danach pflegst. Die Migration von Stencil zu einem managed backend-agnostischen Frontend modernisiert die Storefront ebenfalls, gibt aber die Pflege des Frontend-Fundaments an eine Plattform ab und hält das Backend austauschbar. Beide sind valide. Der richtige Weg hängt davon ab, wie sicher du bei BigCommerce bleibst.

Entscheidungs-Checkliste

Geh das durch, bevor du dich in die eine oder andere Richtung festlegst:

• [ ] Ist BigCommerce für die nächsten drei bis fünf Jahre gesetzt, oder steht es zur Prüfung?
• [ ] Betreibst du, oder erwartest du, mehr als ein Commerce-Backend über Marken oder Märkte?
• [ ] Hast du ein React-Team, das Catalyst- und Next.js-Upgrades langfristig besitzen kann?
• [ ] Braucht Marketing Visual Editing, und ist es relevant, ob dieser Editor an ein Backend gebunden ist?
• [ ] Wenn du von Stencil migrierst, soll der Frontend-Neubau wiederverwendbar sein, falls sich das Backend später ändert?
• [ ] Ist Framework- und Security-Pflege etwas, das dein Team besitzen will, oder an eine Plattform abgeben?

Fazit

Catalyst und Makeswift sind gute Tools, und für ein auf BigCommerce festgelegtes Team sind sie ein klares Upgrade gegenüber Stencil. Das Einzige, was sie dir nicht geben, ist Backend-Flexibilität, weil sie nie dafür gedacht waren. Wenn dein Backend gesetzt ist, ist das kein Problem. Wenn nicht, hält ein backend-agnostisches Frontend die Storefront, die du heute über BigCommerce baust, morgen über einem anderen Backend nutzbar. Der übliche erste Schritt ist ein kurzer technischer Call, um zu klären, welche BigCommerce-Datenpunkte deine Storefront wirklich braucht und ob die agnostische Ebene für dein Setup den Aufwand wert ist.