Ein neues Backend-Feld für Mehrsprachigkeit ist schnell angelegt. Der Teil, der danach Monate dauert…
Saleor + visueller Editor: Wo das Storefront-Template an Grenzen stößt
Saleors Backend ist eines der stärksten Argumente im Open-Source-Commerce: eine GraphQL-first-API, ein moderner Python-Kern und eine Architektur, die euch nie einen monolithischen Storefront aufzwingt. Teams entscheiden sich für Saleor genau deshalb, weil das Backend nicht im Weg steht. Die Reibung entsteht eine Ebene höher, im offiziellen Saleor Storefront selbst, das als Next.js-Template ausgeliefert wird, gebaut für Entwicklerinnen zum Erweitern, nicht für ein Content- oder Marketing-Team zum täglichen Betrieb.
Das Muster ist nicht saleor-spezifisch, es taucht bei jedem GraphQL-first-Backend auf, das keinen eigenen Editor-Layer mitliefert, aber bei Saleor fällt es besonders auf, weil das Backend selbst so wenig zu kritisieren gibt.
Dieser Beitrag bleibt genau bei dieser Nahtstelle: was das Storefront-Template tatsächlich ist, was das Saleor Dashboard tatsächlich zum Bearbeiten von Inhalten bietet, und wo genau die Lücke aufgeht, sobald jemand außerhalb der Entwicklung eine neue Seite veröffentlichen soll. Wenn ihr noch entscheidet zwischen Template, Eigenbau oder einem gemanagten Storefront für Saleor, deckt unser Vergleich der Storefront-Optionen diese vorgelagerte Entscheidung ab. Wenn eure Priorität ist, GraphQL-Komplexität auf der Storefront-Seite ganz zu vermeiden, deckt unser Beitrag zu Saleor für Retailer ohne GraphQL-Overhead diesen Blickwinkel ab. Dieser Beitrag setzt voraus, dass ihr bereits einen funktionierenden Saleor Storefront habt oder gleich haben werdet, und fragt, was passiert, wenn jemand außerhalb der Entwicklung ihn ändern muss.
Was das Saleor-Storefront-Template tatsächlich ist
Das offizielle Saleor-Storefront-Repository beschreibt sich selbst als produktionsreifes Template, gebaut mit React, Next.js App Router, TypeScript, GraphQL und Tailwind CSS, lizenziert unter FSL-1.1-ALv2, das zwei Jahre nach jedem Release zu Apache 2.0 wird. Das ist ein quelloffener Startpunkt, kein gehostetes Produkt. Ihr klont es, verbindet es mit eurem Saleor-GraphQL-Endpunkt, und ab dann ist die Codebase eure eigene, zu pflegen, zu erweitern und zu deployen.
Diese Einordnung ist wichtig, weil sie entscheidet, wo jede künftige Änderung stattfinden muss. Seiten-Layout, Sektionsreihenfolge und Komponentenzusammensetzung leben als React-Komponenten und Routen in der Next.js-Codebase. Es gibt kein datenbankgestütztes Seitenmodell, das steuert, wie eine Landingpage oder eine Kampagnen-Seite aussieht. Soll auf der Startseite eine neue Sektion erscheinen, bearbeitet jemand eine Komponenten-Datei, öffnet einen Pull-Request und deployt ihn. Das Template ist wirklich gut in dem, wofür es gebaut wurde, ein schneller, typisierter, GraphQL-nativer Startpunkt für ein Entwicklungsteam. Es wurde nie als Autoren-Oberfläche für Menschen gebaut, die keinen Code schreiben.
Was das Saleor Dashboard für Inhalte bietet, und was nicht
Saleors eigenes Admin, das Dashboard, enthält tatsächlich eine Content-Funktion: Pages, für Dinge wie eine "About us"-Seite oder eine Richtlinien-Seite. Seit Saleor 3.0 nutzt der Seiteninhalt Editor.js statt des älteren Draft.js, gespeichert als strukturiertes JSON, das ein Storefront beliebig rendern kann, inklusive Read-only-Rendering im Frontend.
Das ist ein wirklich nützliches Werkzeug für statische, textlastige Inhalte. Es ist kein Page-Builder. Editor.js liefert Rich-Text-Blöcke, Überschriften, Listen, Embeds, die Dinge, die eine lange Redaktionsseite braucht. Es liefert kein sektionsbasiertes Layout-System: keine Hero-Blöcke mit konfigurierbaren Spalten, keine Produkt-Grids zum Reinziehen, keine Möglichkeit, vor dem Ausspielen zu sehen, wie eine Änderung tatsächlich im lebenden Storefront aussieht. Wer als Marketerin eine Saleor-Page bearbeitet, verfasst strukturierten Text, nicht ein Seiten-Layout. Sobald eine Änderung visuelle Struktur statt Absatz-Inhalt betrifft, ob es ein neuer Kampagnen-Hero ist, ein umsortiertes Produkt-Karussell oder ein saisonales Banner, hört sie auf, eine Dashboard-Aufgabe zu sein, und wird ein Next.js-Pull-Request.
Wo es in der Praxis reißt
Vier Punkte tauchen konsequent auf, sobald ein Content- oder Marketing-Team versucht, das laufende Publizieren auf dem Stock-Storefront-Template zu betreiben:
- Neue Landingpages brauchen eine Entwicklerin. Weil das Layout Code ist, keine Daten, ist eine neue Kampagnen-Seite eine Build-Aufgabe, keine Content-Aufgabe. Es gibt keinen Self-Service-Weg von "wir brauchen eine Black-Friday-Seite" zu einer veröffentlichten URL, ohne dass jemand das Repository öffnet.
- Änderungen auf Sektionsebene brauchen ein Deploy. Eine Startseite umsortieren, ein Hero-Bild gegen ein anderes Seitenverhältnis tauschen, oder mitten auf der Seite einen Aktionsstreifen einfügen, alles berührt Komponenten-Code, was einen Build, eine Review und eine Deploy-Pipeline bedeutet, selbst für visuell triviale Änderungen.
- Vorschau ist von der Autorenschaft getrennt. Editor.js-Inhalt im Dashboard hat keine Live-Bindung dazu, wie der Storefront ihn tatsächlich rendert. Editorinnen schreiben strukturierten Text im Vertrauen darauf, dass das Frontend ihn korrekt stylt, statt die echte Seitenaktualisierung während der Arbeit zu sehen.
- Lokalisierung ist eine API-Fähigkeit, kein Workflow. PageTranslatableContent existiert, damit übersetzte Felder gespeichert und abgefragt werden können, aber das in einen funktionierenden Multi-Market-Publishing-Workflow zu verwandeln, eine Editorin pro Locale, Freigaben, gestaffelte Ausspielung, muss trotzdem obendrauf gebaut werden. Die API liefert die Datenform, nicht den redaktionellen Prozess.
Nichts davon ist ein Defekt in Saleor. Es ist die direkte, erwartbare Folge davon, ein Open-Source-Storefront-Template für Entwicklerinnen auszuliefern statt ein gehostetes Content-Produkt. Das Storefront-Repository ist explizit als Startpunkt gedacht, der geforkt und angepasst werden soll, und eine geforkte, angepasste Next.js-Codebase ist per Konstruktion etwas, das nur die Entwicklung sicher ändern kann.
Warum das zu einem organisatorischen Engpass wird, nicht nur zu einem technischen
Das Muster ist aus jedem Headless-Stack bekannt, der ein starkes API-Backend von einem reinen Code-Frontend trennt: Die Backend-Entscheidung wird einmal getroffen, von der Entwicklung, und ist wirklich gut. Das Frontend wird dann zur täglichen Oberfläche für Marketing-, Content- und Growth-Teams, die keinen direkten Weg haben, es zu berühren. Jede Kampagnen-Seite, jede saisonale Layout-Anpassung, jede A/B-Test-Variante wird ein Ticket im Entwicklungs-Backlog, das mit Feature-Arbeit um dieselbe Sprint-Kapazität konkurriert.
Für Saleor speziell ist das eine schärfere Version dieses Schmerzes, weil das Backend ungewöhnlich leistungsfähig ist. Teams wählen Saleor wegen seiner API-Tiefe, seines Multichannel-Modells, seiner Erweiterbarkeit, genau der Eigenschaften, die eine GraphQL-first-Architektur für ein Entwicklungsteam attraktiv machen. Dieselbe Tiefe hilft der Marketerin nichts, die einfach nur eine neue Seite live braucht, bevor eine Kampagne am Montag startet. Die Lücke ist kein fehlendes Feature in Saleor. Es ist eine fehlende Ebene zwischen der API und den Menschen, die dagegen publizieren müssen, ohne Code zu schreiben. In vergleichbaren Composable-Setups senkt eine solche Editor-Ebene die Time-to-Launch für neue Landingpages im Schnitt um 65 Prozent gegenüber klassischem Headless-Betrieb, weil genau dieser Ticket-Umweg entfällt.
Was eine Editor-Ebene über Saleor tatsächlich ändert
Genau hier setzt ein Composable Visual Page Builder oberhalb, nicht anstelle, der Saleor-GraphQL-API an. Laioutr verbindet sich direkt mit Saleors Produkt-, Kategorie- und Checkout-Daten, derselben API, die euer Next.js Storefront bereits nutzt, und stellt sie über eine Content Management-Ebene bereit, die ein Marketing-Team ohne Deploy bedienen kann. Bestehende Storefront-Komponenten werden nicht weggeworfen, sie werden als wiederverwendbare Blocks registriert, die der Editor in Studio platzieren, umsortieren und konfigurieren kann, mit einer Live-Vorschau, die an das tatsächliche Rendering gebunden ist, genau die Lücke zwischen Autorenschaft und Rendering schließend, die Editor.js offen lässt.
Die organisatorische Aufteilung, die dabei entsteht, ist genau die, die Saleors eigene Architektur bereits nahelegt, aber selbst nicht liefert: Die Entwicklung behält die Hoheit über Datenmodelle, Integrationen und die zugrunde liegende Komponenten-Logik, während die Rollen Content Manager und Editor Seiten, Kampagnen und Text-Änderungen direkt veröffentlichen. Das ist dasselbe Decoupling-Argument, das Composable Headless Frontend für jedes GraphQL-first-Backend funktionieren lässt: Die API bleibt die Quelle der Wahrheit, und die Editor-Ebene ist das fehlende Stück, das aus API-Tiefe tägliches Publishing-Tempo macht.
Wo das Stock-Template wirklich reicht
Fairerweise zu Saleor: Wenn eure Storefront-Bedürfnisse einfach sind, eine Handvoll statischer Seiten, ein Produktkatalog mit Standard-PLP- und PDP-Layouts, und nicht mehr als gelegentliche saisonale Text-Anpassungen, kann das Storefront-Template plus Dashboard-Pages ein kleines Team lange tragen. Das Problem ist nicht die Existenz des Templates, sondern der Moment, in dem euer Publishing-Takt schneller wird, als eine Entwicklerin mit freier Sprint-Kapazität abfangen kann, was bei den meisten wachsenden Commerce-Marken schneller passiert, als der ursprüngliche Build-Plan angenommen hat.
- Neue Seiten pro Monat. Template reicht: 0 bis 1. Ihr braucht eine Editor-Ebene: Mehrere, nach Kampagnenkalender.
- Wer fordert Änderungen an. Template reicht: Entwicklung selbst. Ihr braucht eine Editor-Ebene: Marketing, Content, regionale Teams.
- Layout-Varianz. Template reicht: Niedrig, meist statische Seiten. Ihr braucht eine Editor-Ebene: Hoch, saisonal und kampagnengetrieben.
- Multi-Market-Publishing. Template reicht: Eine Locale. Ihr braucht eine Editor-Ebene: Mehrere Märkte, jeweils eigener Redaktionstakt.
- Vorschau-Anspruch. Template reicht: Staging-Deploy ist akzeptabel. Ihr braucht eine Editor-Ebene: Echtzeit-Vorschau vor Veröffentlichung erwartet.
Unsere Einschätzung
Saleors Backend verdient seinen Ruf. Das Storefront-Template verdient seinen ebenfalls, als sauberer, typisierter, gut dokumentierter Startpunkt für ein Entwicklungsteam, genau das, was sein eigenes Repository von sich behauptet. Der Mismatch entsteht erst, wenn ein Unternehmen versucht, Marketing-Betrieb durch ein Werkzeug laufen zu lassen, das als Entwickler-Artefakt gebaut und lizenziert wurde. Das ist kein Saleor-Mangel, den es zu beheben gilt, sondern eine Ebene, die nie im Template selbst existieren sollte, und genau die Ebene, die sich lohnt zu ergänzen, sobald euer Publishing-Bedarf größer wird, als Editor.js und eine Deploy-Pipeline tragen können.
Häufig gestellte Fragen
Hat Saleor überhaupt einen visuellen Page-Builder? Nicht im Sinne von Drag-and-Drop-Sektions-Layouts. Die Pages-Funktion im Dashboard deckt strukturierten Rich-Text über Editor.js ab, gut geeignet für statische Inhalte, aber nicht für visuelles Seiten-Layout oder Live-Vorschau.
Können wir unsere bestehenden Next.js-Storefront-Komponenten behalten, wenn wir eine Editor-Ebene ergänzen? Ja. Die Komponenten, die bereits Saleors GraphQL-API aufrufen, müssen nicht neu geschrieben werden, sie werden als Blocks registriert, die ein visueller Editor platzieren und konfigurieren kann, dasselbe Integrationsmuster, das Laioutr für jedes composable Frontend nutzt.
Ist das ein Argument gegen Saleor als Backend? Nein. Das Argument betrifft ausschließlich das Autoren-Modell des Storefront-Templates, nicht die Commerce-API darunter. Saleors GraphQL-Tiefe ist genau das, was eine komponierte Editor-Ebene überhaupt erst möglich macht.
Ändert eine Editor-Ebene etwas an der Lizenz des Storefront-Templates? Nein. Das Storefront-Repository bleibt unter FSL-1.1-ALv2 lizenziert und wird zwei Jahre nach jedem Release zu Apache 2.0, unabhängig davon, ob obendrauf eine Editor-Ebene wie Laioutr angebunden ist. Die Lizenzfrage betrifft den Code der Storefront, nicht die Frage, wer ihn im Alltag bedienen darf.
Nächste Schritte
Wenn euer Team Saleor-Seiten häufiger über Pull-Requests veröffentlicht als über ein Dashboard, bucht eine 30-minütige Demo. Wir schauen uns eure bestehenden Storefront-Komponenten an und zeigen, wie dieselben Seiten mit einer für Marketing bearbeitbaren Ebene obendrauf aussehen.
Mehr von der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr und arbeitet mit Commerce-Teams an der Frontend-Ebene, die zwischen einem composable Backend und den Menschen sitzt, die täglich dagegen publizieren müssen.