Von Saleor zu einem eigenen Shop auf Solidus wechseln

Die Nachricht, die einen Wechsel von Saleor auslöst

Weil Saleor gute Software ist, klingt die Nachricht dazu anders als bei einer geschlossenen Plattform. Von fehlendem Datenzugriff oder einem Anbieter, der dich festhält, ist fast nie die Rede. Eher klingt sie so. Wir sind vor zwei Jahren auf Saleor gestartet, ein Entwickler hat es als GraphQL Shop mit einem React Storefront aufgesetzt, es läuft, doch der Entwickler ist weg, Leute für Python, GraphQL und einen eigenen Frontend zu finden fällt schwer, und ich hätte gern eine Person, der das Ganze gehört. Oder: die Rechnung für Saleor Cloud ist gewachsen, und ob sich die headless Maschinerie für einen Shop meiner Größe lohnt, weiß ich nicht mehr.

Das hier ist meine ehrliche Antwort für ein Unternehmen, das erwägt, Saleor zugunsten eines eigenen Shops auf Solidus zu verlassen, dem quelloffenen Ruby on Rails Framework, auf dem ich baue. Ich bleibe fair, denn Saleor hat das verdient. Der Code gehört dir tatsächlich, die Daten gehören dir, und für das passende Team ist Saleor eine starke Wahl. Der Anlass für einen Wechsel ist fast nie ein Lock in, sondern die Passung. Genau darum dreht sich dieser Artikel: was Passung hier heißt, was wirklich umzieht und wo die eigentliche Arbeit steckt.

Die tiefe, plattformunabhängige Ebene, also wie Kundenkonten, Kataloge, Bestellungen und gespeicherte Karten grundsätzlich umziehen, verlinke ich zu den Datentyp Leitfäden dieser Serie, anstatt sie noch einmal auszubreiten. Fang mit der Säule an, was sich überträgt und was nicht.

Was Saleor ist, und wer bleiben sollte

Saleor benennt sich selbst deutlich. Die eigene Projektdatei nennt es eine headless E Commerce Plattform, gebaut mit Python, GraphQL, Django und React, veröffentlicht unter der BSD 3 Clause Lizenz.¹ Die Startseite des Repositorys spricht von einer GraphQL nativen, reinen API Plattform für Composable Commerce und zählt "Headless and API only" und "GraphQL only" zu ihren prägenden Merkmalen.² Die Architekturübersicht hält fest, dass die Engine in Python geschrieben ist und die API als GraphQL über HTTP oder Message Queues läuft, mit einem schlanken Kern und einem reichen Umfeld externer Anwendungen.³

Zwei Begriffe darin wiegen schwerer als alles andere. "Headless" bedeutet, dass Saleor keinen fertigen Shop Frontend mitliefert. Den Storefront baust du selbst, in der Regel in React oder Next.js, gegen die GraphQL API, und das Dashboard betreibst du als eigene Anwendung. "Composable" bedeutet, dass der Backend aus Commerce Bausteinen besteht, die du zusammenfügst und per Apps und Webhooks erweiterst. Das ist ein bewusster, moderner Entwurf, und für seinen Zweck ist er wirklich gelungen.

Wer sollte demnach auf Saleor bleiben? Ein Team, das Composable, ereignisgesteuerten GraphQL Commerce möchte, das mehrere Storefronts oder Verkaufskanäle auf einem Backend fährt, das Entwickler für Python und Frontend hat oder findet, und das diese Architektur gern besitzt. Passt Saleor zu deinem Unternehmen und sind deine Leute darin produktiv, ist der Umzug auf Solidus ein Seitwärtsschritt mit Kosten und ohne Ertrag. Das sage ich dir im Workshop. Wägst du nur moderne Open Source Optionen gegeneinander ab, ist das ein Vergleich und keine Migration, und der Weg weg von Medusa gehört in dieselbe Schublade.

Wer herauswächst, ist das gespiegelte Profil. Ein einzelner Shop, dem die headless Trennung nichts bringt. Ein Inhaber, der einen verantwortlichen Builder möchte statt eines Python Backends, eines React Frontends und irgendwem, der beide synchron hält. Ein Unternehmen, das lieber im Rails und Solidus Umfeld zu Hause ist. Und ein Shop auf Saleor Cloud, der sich die Rechnung genau angesehen hat.

Was dir gehört, und was wirklich klemmt

An dieser Stelle muss ich genau sein, denn das gängige Migrationsargument greift nicht. Betreibst du die selbst gehostete Ausgabe, gehört dir alles: der Quellcode, die PostgreSQL Datenbank und jede Zeile darin. Die BSD Lizenz lässt dich eigene Änderungen sogar privat halten, ohne jede Pflicht zur Veröffentlichung.⁴ Betreibst du Saleor Cloud, gehören dir weiterhin deine Daten und du darfst gehen. Dir gehört nur die laufende Infrastruktur nicht, und die GraphQL API ist die Tür hinein und hinaus. Saleors eigene Haltung lautet, Cloud sei der beste Weg, das Produkt zu betreiben, und über die Gesamtkosten der günstigste,⁴ und für viele Teams stimmt das.

Nichts davon ist eine Falle. Hat dir jemand erzählt, ein Weggang von Saleor koste dich deine Daten, irrt er, und wem deine Geschäftsdaten eigentlich gehören solltest du lesen, bevor du einem Anbieter an dieser Stelle glaubst. Was im weichen Sinn "klemmt", ist die Gestalt der Sache: nur GraphQL, headless, ein Storefront, den du getrennt pflegst, die Saleor Cloud Preise, sofern du dort bist, und die üblichen Bindungen an Dritte, die jede Plattform kennt, allen voran der Zahlungsanbieter mit deinen Karten Token und das, was deine Abonnements betreibt. Ich nehme sie der Reihe nach.

Export und API in der Praxis

Saleor ist API first, und die API ist GraphQL, ohne REST Schnittstelle als Ausweichweg.² Das prägt jeden Export, den du vornimmst.

Für den Katalog existiert ein eingebauter Produktexport. Das Dashboard und die Mutation exportProducts liefern eine CSV oder XLSX Datei, bezogen auf alle Produkte, eine gefilterte Auswahl oder eine Liste von IDs, mit den Feldern und der Spaltenfolge deiner Wahl, und die fertige Datei erreicht dich als Downloadlink per E Mail.⁵ Sie umfasst Produkte und Varianten samt Attributen, Lagermengen und Preisen je Kanal und ist das sauberste Einzelwerkzeug überhaupt. Kunden oder Bestellungen liefert sie nicht.

Die ziehst du über die GraphQL API mit geschriebenen Abfragen. Drei Grenzen bestimmen den Weg. Paginierte Felder geben höchstens 100 Einträge pro Seite zurück, über Cursor basierte Paginierung, ein vollständiger Export ist also eine Schleife entlang der Cursor.⁶ Die Abfragekosten bemessen sich an der Zahl der angeforderten Objekte, nicht der gelieferten, und der Server lehnt alles oberhalb seiner Obergrenze ab und nennt Kosten und Limit in jeder Antwort.⁶ Beim Rate Limiting zerfällt das Bild: freie Saleor Cloud Sandboxes lassen 120 Anfragen je Minute zu und bezahlte 2.000, darüber antwortet die API mit HTTP 429, während produktive Cloud Umgebungen und selbst betriebene Installationen kein festes Limit tragen, wobei die Produktion Verkehr bremsen darf, der den Dienst beeinträchtigt.⁶ In der Praxis ist eine Migration aus der Cloud ein geduldiges, getaktetes Absuchen der API, einmal geschrieben und so oft wiederholt, bis es öde wird.

Hostest du selbst, steht dir ein kürzerer Pfad offen: direkter Zugriff auf die PostgreSQL Datenbank, der zügigste Weg, einen großen Katalog und die Bestellhistorie in Masse zu verschieben. In der Cloud gibt es keinen Datenbankzugriff, dort sind die GraphQL API und der Produktexport das gesamte Werkzeug.

Eines kommt nie in brauchbarer Form mit, bei Saleor so wenig wie sonst wo: Passwörter. Sie liegen gehasht vor, Kunden vergeben also beim ersten Besuch im neuen Shop ein neues. Das ist eine Kampagne zum Planen, kein technisches Hindernis, und der Leitfaden zu Kundenkonten und Adressen zeigt, wie sie gelingt, ohne dir am Umstelltag das Postfach zu überfluten.

Der ehrliche Hebel: eine Anwendung statt zweier

Headless ist ein Merkmal, kein Makel. Für einen kleineren Shop ist es zugleich der Kern. Auf Saleor betreibst du mindestens die Python Engine, einen selbst gebauten und gepflegten Storefront und das Dashboard, dazu Apps und Webhooks rundherum für Zahlungen und den Rest.³ Das sind zwei oder drei Codebasen, zwei oder drei Deploy Strecken und zwei Kompetenzen: Backend Python und GraphQL hier, ein JavaScript Storefront dort. Einem großen Team mit vielen Kanälen bringt diese Trennung Rendite. Einem einzelnen Shop beschert sie viele bewegliche Teile, die synchron bleiben müssen, und der Tag, an dem der Entwickler geht, der beide durchschaut hat, ist der Tag, an dem es wehtut.

Ein Solidus Shop ist eine Ruby on Rails Anwendung. Solidus ist quelloffen unter der BSD 3 Clause Lizenz, bringt eine REST API mit und ist eine gewöhnliche Rails Anwendung mit den Testwerkzeugen, dem Deploy Weg und dem Bewerberpool, den das mit sich bringt.⁷ Headless kannst du weiterhin, wenn du es brauchst: headless und API first Solidus zeigt, wie derselbe Shop später eine mobile App oder einen zweiten Storefront versorgt. Nur wirst du am ersten Tag nicht in diese Trennung gezwungen, wenn dein Shop sie nicht braucht. Eine Anwendung, ein verantwortlicher Builder, eine Stelle, an der du nachsiehst, wenn etwas bricht. Das ist, weit mehr als jedes Datenargument, der Grund, warum eine bestimmte Sorte Saleor Shop auf Solidus besser liegt.

Zahlungen, gespeicherte Karten und der Anbieter

Saleor wickelt Zahlungen nicht selbst ab. Es bindet Anbieter wie Adyen über Apps und Transaktions Webhooks an, und die Kartendaten und die wiederverwendbaren Token liegen beim Anbieter, nicht in Saleor.⁸⁵ Für einen Umzug ist das eine gute Nachricht. Der beste Fall räumt die schwerste Frage komplett ab: zahlt dein Shop bereits über ein eigenes Konto bei Stripe, Adyen oder ähnlich, dann verbindet sich der neue Solidus Shop mit demselben Konto und die gespeicherten Karten bleiben unverrückt.

Wechselst du dagegen mit dem Umzug den Anbieter, reisen gespeicherte Karten nur zwischen nach PCI DSS Level 1 zertifizierten Anbietern, und selbst dann betrifft der Export allein die Karten, nicht die daran hängenden Abonnements oder die Zahlungshistorie.⁹ Das gehört ins erste Gespräch, nicht in die letzte Woche, und der Leitfaden zu Zahlungstoken und gespeicherten Karten listet die Fragen, die du deinem Anbieter stellst, ehe du dich auf ein Datum festlegst.

Abonnements, falls du welche betreibst

Saleors Kern ist ein Satz Commerce Bausteine, keine Abo Engine, deshalb läuft wiederkehrende Abrechnung auf Saleor meist über eine App oder einen externen Dienst, der per Webhooks hängt. Fürs Umziehen heißt das: "was genau betreibt die Abonnements, und wo liegen Zeitpläne und Mandate" ist die Frage, die du vor allem anderen klärst, denn ein aktives Abonnement ist das härteste Objekt jeder Migration. Der Leitfaden zu Abonnements und wiederkehrenden Zahlungen führt die Fälle vor, vom sauberen Umschalten bis zum sanften Übergang, bei dem beide Systeme ein bis zwei Abrechnungszyklen parallel laufen.

SEO und die Weiterleitungskarte

Weil dir der Storefront auf Saleor gehört, gehören dir auch die URLs. Welche Pfade deine React oder Next.js Anwendung für Produkte, Kategorien und Inhalte verwendet, das sind jene, die deine Rankings und deine eingehenden Links tragen, und sie müssen im neuen Shop sinnvoll ankommen. Die Regel gleicht der jedes Umzugs: erfasse jede alte URL, die im letzten Jahr einen Besuch oder einen Link erhalten hat, bilde sie auf ihre neue Adresse ab und liefere eine dauerhafte Weiterleitung, fast immer eine 301, die direkt aufs endgültige Ziel zeigt und nicht über eine Kette. Halte die Weiterleitungen mindestens ein Jahr, und dauerhaft, wenn möglich.¹⁰ Der Leitfaden zu Produkt und Katalogdaten zeigt, wie Katalog und URLs gemeinsam umziehen, woher der Großteil der Weiterleitungskarte stammt.

Der Umzug, auf die Datenleitfäden abgebildet

Hier die Gestalt eines Saleor Umzugs auf einer Seite. Jede Zeile verweist auf den Leitfaden mit der Tiefe, damit dieser Artikel bei Saleor bleibt und nicht wiederholt, was jene abdecken.

Der Shop bleibt durchweg der Verantwortliche für seine Kundendaten, und die Plattform, der Hoster und ich sind jeweils Auftragsverarbeiter, die einen schriftlichen Auftragsverarbeitungsvertrag nach Artikel 28 der DSGVO brauchen.¹¹ Eine Migration verlangt keine neue Einwilligung von jedem Kunden, aber sie verlangt die Einwilligungsnachweise, mit Zeitstempel und Wortlaut, mitgenommen und nicht auf ein Ja oder Nein eingedampft.

Ein durchgerechnetes Beispiel: Lindenauer Röstwerk

Das Lindenauer Röstwerk (lindenauerroest.example) ist eine erfundene Leipziger Kaffeemarke mit etwa 1,2 Millionen Euro Online Umsatz im Jahr. Sie röstet auf Bestellung, verkauft Bohnen und Brühgerät und fährt einen Kaffeeklub, der alle zwei oder vier Wochen liefert, grob ein Drittel des Umsatzes. Vor zwei Jahren hat ein Entwickler sie auf Saleor Cloud Select gebaut, mit einem Next.js Storefront und Stripe für Zahlungen, und es lief gut.¹² Das Problem sind die Leute, nicht die Plattform. Dieser Entwickler arbeitet inzwischen auf eigene Rechnung und ist schwer zu bekommen, der Inhaber findet keine einzelne Person, die in Python und im React Storefront zugleich stark ist, und das Cloud Abo samt Kaffeeklub Werkzeug ist eine Position, die auffällt. Er will einen Shop, einen Builder und das Rails Umfeld, das er für die internen Werkzeuge der Rösterei ohnehin nutzt.

Ich würde es in dieser Reihenfolge angehen. Zuerst die zwei Fragen, die ein Datum kippen können. Zahlungen: der Shop besitzt sein Stripe Konto schon, der Solidus Aufbau verbindet sich also mit demselben Konto und die gespeicherten Karten bleiben einfach liegen, womit der schwerste Punkt vom Tisch ist. Abonnements: der Kaffeeklub läuft über eine in Saleor eingebundene App, also kläre ich vor allem anderen, wo Zeitpläne und Stripe Mandate wirklich liegen, und plane den Klub als eigenes kleines Projekt, sehr wahrscheinlich mit beiden Systemen für einen Abrechnungszyklus, damit keine Verlängerung ausfällt.

Dann die Daten. Der Katalog kommt über Saleors Produktexport als CSV heraus, Varianten, Attribute, Lager und Preise je Kanal inbegriffen, und bildet sich sauber auf Solidus Produkte und Varianten ab.⁵¹³ Kunden und Bestellhistorie kommen über die GraphQL API, ein getaktetes Absuchen, das den Cursorn 100 Datensätze auf einmal folgt und gut im Rahmen der Grenzen des Select Tarifs bleibt,⁶ als reine Lesehistorie der letzten drei Jahre hereingeholt, der vollständige Export archiviert. Passwörter bleiben unberührt, jedes Konto entsteht im neuen Shop bereit zur Freischaltung, und eine Servicenachricht vor dem Umschalten erklärt Klubmitgliedern und Kunden, was beim ersten Besuch zu tun ist.

Der Storefront entsteht als Teil der Solidus Anwendung neu, und das ist der Zweck der Übung: eine Rails Codebasis statt einer Python API und einer getrennten Next.js Anwendung. Die Weiterleitungskarte wächst aus den Next.js Routen, jede Produkt, Sammlungs und Inhalts URL auf eine 301 im neuen Shop abgebildet und vor dem Start geprüft. Ein dreiwöchiger Parallelbetrieb auf einer Staging Adresse, ein Katalogstopp in dieser Zeit, zwei Proben des finalen Imports und ein Umschalten an einem ruhigen Dienstagvormittag außerhalb der Röstsaison. Die alte Saleor Umgebung bleibt dreißig Tage unberührt stehen als Rückfallebene, danach ein letzter Export und die Kündigung.

Der ehrliche Teil: das erste Jahr kostet das Lindenauer Röstwerk mehr, als ein Jahr Saleor Cloud Select gekostet hätte. Dafür erhält er eine einzige eigene Rails Anwendung, kein monatliches Cloud Abo und keine Mehrkostengebühr auf Wachstum, und eine Person, die er anruft. Für einen Shop seiner Größe lohnt sich dieser Tausch. Für einen Shop halb so groß, ohne Abonnement und mit einem zufriedenen Entwickler, lohnt er sich nicht, und auch das würde ich ihm sagen.

Wann du nicht wechseln solltest

Bleib auf Saleor, wenn die headless, GraphQL Architektur etwas ist, das du aktiv willst und nutzt: mehrere Storefronts, intensive Nutzung des Ereignismodells, ein Team, das darin sicher ist. Bleib, wenn deine einzige Klage die Cloud Rechnung ist und die Rechnung tragbar bleibt, denn eine Migration trägt ein Risiko, das eine tragbare Rechnung nicht trägt. Bleib, wenn du die Person auf deiner Seite noch nicht benennen kannst, die die Daten, die Varianten und die Klubkunden versteht, denn ohne sie bekommst du einen schmucken neuen Shop voller falscher Daten. Und wechsle nie in den Wochen vor deiner Hochsaison.

Wechsle, wenn der Shop eine einzelne Anwendung ist, die sich als Plattformteam ausgibt, wenn du einen verantwortlichen Builder und das Rails Umfeld willst, und wenn die Saleor Cloud Preise für einen Shop deiner Größe aufgehört haben, zum Wert zu passen. Willst du die Fünfjahresrechnung dahinter, arbeite ich sie in den Gesamtkosten eines Umzugs auf Solidus durch, und ich vergleiche die wichtigsten Plattformen ehrlich in Solidus gegen Shopify, Shopware, Magento und WooCommerce.

Zum Schluss

Saleor ist keine Plattform, von der ich abrate. Es ist ein fähiges, quelloffenes, GraphQL natives Projekt, und wenn es zu deinem Team passt, passt es. Die Unternehmen, denen ich davon weghelfe, sind jene, bei denen die Passung leise zerbrochen ist: ein einzelner Shop, der das Gewicht einer Composable Architektur trägt, die er nicht braucht, ein Inhaber, der einen Builder statt zweier Disziplinen will, eine Cloud Rechnung, die nicht mehr aufgeht. Für sie ist ein eigener Solidus Shop weniger Aufwand, leichter zu besetzen und ganz der ihre.

Klingt das nach deinem Shop, dann bring das echte Bild in einen kostenlosen Workshop, und die ersten zwei Wochen Arbeit gehen auf mich. Ich sage dir ehrlich, ob sich ein Wechsel lohnt, und wenn Saleor weiterhin das richtige Zuhause für dich ist, sage ich das.