Offline-first is een architectuur
Veldapps hebben geen betere foutafhandeling voor verbroken verbindingen nodig. Ze hebben een datamodel nodig waarin het netwerk nooit is verondersteld.
Er bestaat een versie van offline-ondersteuning waarbij de app een verbroken verbinding detecteert, een melding toont en het opnieuw probeert. Dat werkt in een demo en faalt in een kelder, want het probleem is niet het verzoek — het is dat de gebruiker veertig minuten doorwerkte terwijl het verzoek onmogelijk was.
Offline-first draait de verhouding om. De lokale database is de bron van waarheid. De interface leest en schrijft lokaal en wacht nooit op een netwerkaanroep. Synchronisatie is een achtergrondproces dat afstemt wanneer het kan, en de gebruiker wordt er nooit door geblokkeerd.
Daarmee is de uitgaande wachtrij het belangrijkste onderdeel van de app. Elke mutatie wordt vóór uitvoering aan een duurzaam journaal toegevoegd, zodat een app die halverwege een upload wordt afgesloten hervat bij de laatste goede regel in plaats van het werk te verliezen. Dat is het verschil tussen een monteur die 's avonds een dag aan opdrachten overtikt en een die dat niet doet.
Conflicten worden dan een productbeslissing in plaats van een technisch ongeluk, en ze horen vóór de eerste regel code te zijn afgesproken. Bij veldservice kwamen we uit op server-wint voor prijzen en planning, toestel-wint voor waarnemingen die de monteur ter plaatse deed, en een uitzonderingswachtrij voor al het overige.
Payloadgrootte telt zwaarder dan teams verwachten. Deltasync in plaats van volledige verversing, gecomprimeerde en hervatbare fotouploads, en een hard budget voor wat een synchronisatie kost aan data en batterij. Een correcte app die de telefoon tegen lunchtijd leegtrekt, is geen werkende app.
Bij een uitrol onder negenhonderd montagemonteurs bracht dit de doorlooptijd per opdracht met tweeënveertig procent omlaag en het aantal verloren opdrachten van circa veertig per maand naar nul. Niets daarvan kwam uit de interface.