my-advent
LiveDigitale Adventskalender zum Verschenken — Marketing, Kundenportal, Backoffice und eine multi-tenant Kalender-PWA.
Einen digitalen Adventskalender zu verschenken heißt: für jeden Tag bis Weihnachten ein Foto aussuchen, etwas dazu schreiben und das Ganze rechtzeitig in die Hände des Beschenkten bringen. Der Vorgänger dieses Projekts konnte das schon, aber jede Bestellung endete bei einem Menschen, der von Hand einen Container startete, ein Zertifikat ausstellte und einen Eintrag im Proxy anlegte. Acht Bestellungen einer einzigen Interessentin blieben so liegen, vier davon mit fertig gefülltem Kalender — online ging keiner.
my-advent ist der Neubau davon: ein Monorepo mit zwei laufenden Anwendungen. Die eine trägt Marketing-Seite, Kundenportal, Backoffice und die Programmierschnittstelle; die andere bedient sämtliche Kundenkalender, und welcher gemeint ist, steht in der aufgerufenen Adresse. Zwischen der bezahlten Bestellung und dem verschickbaren Link steht damit kein Mensch mehr. Geht eine der automatischen Prüfungen schief, wartet nicht der Kunde stumm, sondern der Betreiber bekommt Bescheid.
Bemerkenswert ist, wie viel dabei weggefallen ist: keine Containerverwaltung aus der Anwendung heraus, kein Zertifikat je Kunde, kein eigener Zahlungsdienst, kein Datenbankserver. Was bleibt, sind zwei Container, eine Datenbankdatei und ein Verzeichnis mit Bildern. Geblieben sind auch drei bewusst verschiedene Zugänge, je nachdem, wer kommt: Wer beschenkt wird, soll gar nichts einrichten müssen; wer kauft, so wenig wie möglich; wer den Laden betreibt, meldet sich richtig an. Jede Gruppe bekommt den Aufwand, der ihr zuzumuten ist, und keinen darüber hinaus.
Entscheidungen
Ein Dienst für alle Kalender statt ein Container pro Kunde
Vorher bekam jeder Kunde eine eigene laufende Instanz samt Proxy-Eintrag und Zertifikat; das Backoffice brauchte dafür Rechte, die praktisch denen des Serveradministrators entsprachen, und jede Bestellung war eine Kette von Schritten, die an mehreren Stellen scheitern konnte. Die Abschottung, die man damit erkauft, wird nirgends gebraucht: Alle Kalender laufen mit demselben Code, und die Bestelldaten liegen ohnehin gemeinsam. Einen Kalender anzulegen heißt jetzt, eine Zeile in die Datenbank zu schreiben.
Fremder Bezahlvorgang statt eigenem Zahlungsdienst
Bezahlt wurde bisher über einen selbst gebauten Dienst: rund 3.000 Zeilen für genau einen Anbieter, mit dem Zugangsgeheimnis im Protokoll und leeren Fehlerbehandlungen. Der gehostete Bezahlvorgang kostet weniger Gebühr, bringt Apple Pay und Google Pay mit — bei einem Impulskauf von knapp fünf Euro auf dem Handy der entscheidende Punkt — und erzeugt die Rechnung mit Steuerausweis gleich mit. Der Preis dafür ist die Abhängigkeit von einem fremden Dienst; die Alternative war ein eigener Zahlungsdienst mit geloggtem Geheimnis.
Kein Benutzerkonto für den Beschenkten
Erwogen war, für jeden Kalender ein Konto in einem eigenen Anmeldedienst anzulegen. Die Beschwerde aus der Praxis — „man muss sich ständig neu einloggen“ — war aber kein Problem der Identität, sondern der Cookie-Laufzeit; Konten hätten sie nicht behoben, dafür aber Großeltern durch einen Anmeldeablauf geschickt, die nur ein Foto sehen wollen. Behoben wurde deshalb, was wirklich kaputt war — die Laufzeit —, und nicht das, was danach aussah.
Erst gestalten, dann zahlen
Die umgekehrte Reihenfolge wäre einfacher gewesen: keine unbezahlten Entwürfe, die Platz belegen und sich missbrauchen lassen. Wer aber 24 Fotos ausgesucht und Nachrichten dazu geschrieben hat, hat eine halbe Stunde investiert, und diese Arbeit ist das stärkste Kaufargument, das das Produkt hat — hinter der Bezahlschranke wäre sie verschenkt. Die Entwürfe entstehen deshalb schon vor der Bezahlung auf dem Server und verfallen nach 30 Tagen.