E-Commerce von Grund auf entwickeln, mit Logistikanbindung: die fünf Schichten und die Reihenfolge ihres Aufbaus

«Ich möchte einen Onlineshop von Grund auf neu» heißt meist «Ich möchte einen Shop, der das kann, was Vorlagen nicht können». Und was Vorlagen nicht können, ist fast immer dasselbe: mit dem Hersteller, dem Versender und dem Zahlungsdienst zu sprechen, ohne dass jemand Daten von einem Bildschirm auf den anderen abtippt. Dieser Artikel erklärt, wie wir diese Arbeit in fünf Schichten gliedern, was jede enthält und in welcher Reihenfolge sie gebaut werden. Die Beispiele stammen von eclipseando.com, einem eigenen Shop von uns im Produktivbetrieb, und von den Zusteller-Konnektoren, die wir für Odoo veröffentlicht haben.

Die fünf Schichten eines Shops

Schicht 1: Die Daten liegen an einem einzigen Ort

Bevor man einen Bildschirm entwirft, muss feststehen, wo der Katalog liegt. Hat der Kunde Odoo, lautet die Antwort Odoo: Produkte, Preise, Bestand und Aufträge sind dort, und die Website liest sie, statt sie zu kopieren. Hat er es nicht, braucht der Shop eine eigene Datenbank, und sie sollte klein und unspektakulär sein. Bei eclipseando.com ist es SQLite, in einer Datei, mit Datensicherung. Es darf nicht passieren, dass der Preis auf der Website, in einer Tabellenkalkulation und im ERP steht: Nach zwei Monaten sind es drei verschiedene Preise.

Schicht 2: Die Kasse vertraut dem Browser nicht

Zwei Regeln, über die wir nicht verhandeln. Erstens: Der Preis wird auf dem Server berechnet, mit dem aktuellen Katalog, in dem Moment, in dem die Zahlungssitzung erstellt wird. Der Browser darf den Warenkorb speichern, aber nicht bestimmen, was er kostet. Zweitens: Eine Bestellung gilt als bezahlt, wenn das Gateway sie per signiertem Webhook bestätigt, nicht wenn der Kunde auf der Dankeseite landet. Bei Stripe ist das checkout.session.completed mit verifizierter Signatur; andere Gateways nennen es anders, die Idee ist dieselbe. Und schlägt beim Eingang des Webhooks der nächste Schritt fehl, antwortet man mit einem Fehler, damit das Gateway es erneut versucht, und speichert die Sitzungs-ID, um nichts doppelt zu fertigen.

Schicht 3: Jeder Lieferant spricht so, wie er kann

Hier hört «Logistikanbindung» auf, ein Schlagwort zu sein, und wird zur Arbeit. Ein Lieferant mit API und Webhook (eine Druckerei auf Abruf, ein großer Zusteller) wird in beide Richtungen angebunden: Beim Bezahlen wird ihm die Bestellung angelegt, und seine Meldung «versendet» wird abgehört, um die Sendungsverfolgung an den Kunden weiterzugeben. Einer mit Dropshipping-API wird in eine Richtung angebunden und in der anderen abgefragt: vor dem Bezahlen die tatsächliche Verfügbarkeit pro Land, danach die Bestellung. Und einer ohne API, von denen es viele gibt, wird angebunden, indem die menschliche Arbeit auf einen Klick reduziert wird: Das System erzeugt genau die E-Mail oder CSV-Datei, die der Lieferant braucht, und wenn seine Pakete mit einem Zusteller versendet werden, der E-Mails schickt, werden diese E-Mails gelesen und in Status umgewandelt.

Zwei Details, die man nur mit echten Bestellungen lernt. Erstens: Die Sendungsverfolgung läuft pro Sendung, nicht pro Bestellung, denn eine Bestellung mit zwei Produkten von zwei Lieferanten sind zwei Pakete. Zweitens: Die Lieferzeiten aus der Dokumentation des Lieferanten sind nicht die, die er einhält; man misst sie, indem man Testbestellungen anlegt und liest, was zurückkommt, und genau diese Zeiten zeigt man dem Kunden vor der Zahlung. Ist der Lieferant ein Zusteller und der Shop läuft mit Odoo, ist all das in den von uns veröffentlichten Zusteller-Konnektoren bereits gelöst: Etikett, Sendungsverfolgung, Manifest und Retoure direkt im Lieferschein.

Schicht 4: Was von selbst läuft und was wiederholt wird

Ein Shop hat Arbeiten, die nicht davon abhängen dürfen, dass jemand daran denkt: die E-Mail-Warteschlange leeren, bezahlte Bestellungen erneut senden, die nie beim Lieferanten ankamen, das Postfach des Zustellers lesen, den Bestand mit Marktplätzen abgleichen. Jede davon ist eine geplante Aufgabe mit Intervall und Protokoll. Die Entwurfsregel lautet, dass keine von ihnen im Pfad einer Benutzeranfrage einen externen Dienst aufruft: Die Seite liest, was die Aufgabe im Cache hinterlassen hat. Fällt der Lieferant um drei Uhr nachts aus, liefert der Shop so weiter Seiten aus, und die Bestellungen werden erneut versucht, sobald er zurück ist.

Schicht 5: Das Frontend, am Ende und schnell

Sind die vier unteren Schichten gelöst, ist das Frontend der dankbarste Teil. Wir bevorzugen statische Seiten, die beim Build erzeugt und von nginx oder Caddy ausgeliefert werden (Astro bei eclipseando.com): Sie laden blitzschnell, haben keine Datenbank, die man angreifen könnte, und kosten so viel wie ein kleiner Server. Das Dynamische (Warenkorb, Zahlung, Bestellstatus) läuft über eine separate API. Mehrsprachigkeit wird mit einer URL pro Sprache und eigenen Texten umgesetzt, nicht mit einem automatischen Übersetzer obendrauf, und mit Tests abgesichert, die prüfen, dass jede Vorlage in allen Sprachen existiert. Und die Geschwindigkeit wird vor der Veröffentlichung gemessen: Seitengewicht, Bilder in der Größe, in der sie dargestellt werden, nichts, was das erste Rendering blockiert.

Die Reihenfolge zählt: von innen nach außen

Der teuerste Fehler, den wir sehen, ist, mit Schicht 5 anzufangen. In der zweiten Woche wird eine schöne Website gezeigt, der Kunde freut sich, und die Schichten 1 bis 4 werden darunter in Eile improvisiert. Das Ergebnis funktioniert bis zur ersten Bestellung mit zwei Lieferanten oder bis zum ersten verlorenen Webhook. Wir bauen umgekehrt: zuerst Daten und Kasse mit ihren Tests, dann die Anbindungen mit echten Testbestellungen, dann die geplanten Aufgaben, und das Frontend zuletzt, wenn genau feststeht, was es zeigen muss. Es dauert genauso lang. Man muss deutlich weniger neu machen.

Häufige Fragen

Nützliche Links bei FlexigoTech

Was wir dazu machen