PWA zur Selbstverwaltung von Fahrzeugbetrieb

Problem

Der Selbstverwaltungspfad setzte noch einen besetzten Schalter oder eine brüchige mobile Site voraus. Halter konnten die Kernschleife nicht vom Telefon aus abschließen. Angrenzende Ops-Tools (Backoffice, Picker und Client-Apps) waren aus der gemeinsamen Version gedriftet, sodass eine Änderung in einer Oberfläche in den anderen nicht überlebte.

Vorgaben

Das Produkt musste als PWA ausgeliefert werden, nicht als Store-App. Bestehende Identitäts- und Policen-Systeme blieben die Quelle der Wahrheit; ein Rewrite dieser Systeme war außerhalb des Umfangs. Die Testabdeckung musste mit dem Neubau steigen, nicht danach. Dieser Text beschreibt nicht den Versicherer, den Fahrzeugkatalog oder irgendeine Produktionsoberfläche.

Architektur

Version 2.0 der halterseitigen Oberfläche wurde in React von Grund auf als PWA gebaut: installierbar, offline-tolerant für die letzte bekannte Sitzung und von einem typisierten API-Client getrieben. Eine gemeinsame Komponenten- und Vertragsschicht hielt Backoffice, Picker und Client-Apps auf derselben Versionslinie. TDD deckte etwa drei Viertel der neuen Arbeit ab, sodass Regressionen in der Halterschleife sich nicht in den Ops-Tools verstecken konnten. Ein separater Electron-Kiosk übernahm die Interaktion vor Ort, ohne das Routing der PWA zu teilen.

Rolle

Als technischer Frontend-Lead habe ich den PWA-Neubau verantwortet, die gemeinsame Vertragsschicht über die drei Ops-Oberflächen und die Testdisziplin, die dieses Teilen sicher machte. Ich habe auch den Electron-Kiosk als eigenen Pfad vor Ort ausgeliefert.

Ergebnisse

• Halter konnten die Selbstverwaltungsschleife aus dem Browser abschließen, ohne native Installation.
• Backoffice, Picker und Client-Apps bewegten sich als eine Version statt als drei Forks.
• TDD über etwa 75 % der neuen Arbeit machte die gemeinsamen Verträge durchsetzbar.

Stack