In einer Serie von Blogposts geben wir dir einen Einblick, was bei der Entwicklung der viaVelo Platform und den zugehörigen Apps hinter den Kulissen abgeht.
In diesem Artikel zeigen wir dir, wie wir die viaVelo Schnittstelle zur Programmierung von Anwendungen (API) mit Versionschecks und Monitoring wartbar halten ohne den Anwendenden zu viele App-Updates zumuten zu müssen.
Entwickler mobiler Applikationen die auf eine API zugreifen kennen das Problem der Rückwärtskompatibilität. Wird eine neue Version der API eingeführt, muss diese mit allen Beziehenden von Daten (Clients) umgehen können, die im Umlauf sind. Bei viaVelo nutzen wir additive Änderungen um Rückwärtskompatibilität zu gewährleisten. Wie dies funktioniert erklären wir an einem Beispiel:
Wir wollen auf der API das Feld name in prename und surname aufteilen.
Eine gängige Technik um eine solche Änderung rückwärtskompatibel umzusetzen sieht vor, dass wir zuerst die beiden neuen Felder prename und surname einführen. Das bisherige Feld name markieren wir als veraltet (deprecated). Anschliessend passen wir alle Clients so an, dass sie nur noch auf die neuen Felder und nicht mehr auf das veraltete Feld zugreifen. Sobald kein Client mehr auf das name Feld zugreift, können wir es aus der API entfernen.
Bei viaVelo sind die Clients der API unter anderem mobile Applikationen. Wir können nicht beeinflussen, wann die Anwendenden die Applikationen aktualisieren. In unserem Beispiel bedeutet dies, dass wir das Feld name über längere Zeit nicht löschen können.
Über Zeit kommen mehr solcher API Änderungen hinzu und die API wird immer komplexer und aufwändiger zu warten.
Um dieses Problem zu mildern, haben wir bei allen viaVelo Apps einen Versionscheck eingebaut. Damit können wir die Anwendenden zwingen ihre Applikation zu aktualisieren und wir können veraltete Felder aus der API entfernen.
So funktionierts:
Bei jedem Zugriff (Request) auf die API senden die mobilen Applikation ihre Version in einem Header-Feld mit. Die API hat für jede mobile Applikation die minimal kompatible Version gespeichert. Ist die von der mobilen Applikation gesendete Version nicht kompatibel, wird der HTTP Status Code 412 (Precondition Failed) zurückgegeben.
Auf den mobilen Applikationen fangen wir diesen Status Code ab und zeigen den Anwendenden einen Hinweis, dass sie die Applikation aktualisieren müssen um den Service weiterhin nutzen zu können.
Aber wie bestimmen wir, wie lange die mobilen Applikationen mit der API kompatibel sind? Dazu nutzen wir unser Monitoring. Wir wissen ja bereits, dass die mobilen Applikationen bei jedem API Request die Version als Header Feld mitsenden.
Dieses fügen wir unseren Metriken als Label hinzu. Das erlaubt es uns über einen beliebigen Zeitraum auszuwerten, welche Versionen noch im Einsatz sind.
Anhand dieser Daten bestimmen wir, welche Versionen wir noch unterstützen wollen. Zudem können wir abschätzen wie viele Anwendende ihre App aktualisieren müssen, falls wir entscheiden eine Version nicht mehr zu unterstützen.
So versuchen wir eine Balance zwischen der Wartbarkeit der viaVelo API und dem Anwendungserlebnis der Apps zu finden.
