Eine Zapier- oder Make-Automatisierung auf einen neuen Geokodierungs-Host migrieren
No-Code-Automatisierungen mit einem Geokodierungsschritt brauchen einen anderen Migrationsansatz als eigener Code. So gehen Sie bei diesem Wechsel vor.
Die Geokodierungsaufrufe einer mobilen App migrieren
Die Migration von Geokodierungsaufrufen, die direkt aus einer mobilen App erfolgen, bringt einige Einschränkungen mit sich, mit denen eine rein serverseitige Migration nicht umgehen muss, und es lohnt sich, sie vor dem Start klar zu benennen, da sie die Form des Plans verändern.
Die erste ist der Veröffentlichungsrhythmus. Eine serverseitige Änderung kann live gehen, sobald sie ausgerollt ist. Eine Änderung an einer mobilen App muss die Prüfung im App Store durchlaufen, und die Verbreitung hängt dann davon ab, dass Nutzer tatsächlich aktualisieren, was bei vielen Apps Wochen dauert, bis eine Mehrheit der installierten Basis erreicht ist, und deutlich länger, bis alle erreicht sind. Jeder Migrationsplan für eine mobile App muss berücksichtigen, dass zwei Anbieter oder zwei Versionen der App länger parallel laufen, als es eine Servermigration typischerweise erfordert.
Die zweite ist die Offenlegung von Zugangsdaten. Ein API-Schlüssel, der direkt in die Binärdatei einer mobilen App eingebettet ist, kann von jedem extrahiert werden, der sich die Mühe macht, danach zu suchen, und das ist ein Sicherheitsaspekt, unabhängig davon, um welchen Anbieter es geht. Wenn Ihre aktuelle Integration eine Geokodierungs-API direkt vom Client mit einem eingebetteten Schlüssel aufruft, ist eine Migration ein guter Moment, dieses Muster zu überdenken und den Aufruf stattdessen hinter Ihr eigenes Backend zu verlegen, auch wenn das etwas Latenz und etwas Backend-Arbeit hinzufügt.
Einige praktische Schritte, die für die meisten mobilen Migrationen gelten:
- Wenn Sie den Aufruf auf den Server verlagern, entwerfen Sie zuerst den neuen Backend-Endpunkt und bringen Sie die mobile App dazu, mit Ihrer eigenen API zu sprechen, bevor Sie sich darum kümmern, welcher Anbieter dahintersteht, und entkoppeln Sie so die Änderung in der App vollständig von der Änderung beim Anbieter
- Wenn Sie den Aufruf auf dem Client belassen, verwenden Sie für API-Host und Schlüssel einen Konfigurationswert zur Build-Zeit, statt sie fest einzucodieren, damit eine künftige Migration nicht erneut das Suchen und Ersetzen einer literalen Zeichenkette in der gesamten Codebasis erfordert
- Testen Sie mit tatsächlich noch verbreiteten älteren App-Versionen, nicht nur mit dem neuesten Build, wenn Sie während einer Übergangszeit beide Anbieter unterstützen wollen, denn eine alte App-Version, die einen alten, bald abgeschalteten Host aufruft, ist ein realistisches Szenario, das eine ausdrückliche Entscheidung darüber verdient, wie lange Sie es noch unterstützen
Die Authentifizierungsoptionen von My Geocode, ein X-API-Key-Header, ein Authorization: Bearer-Header, HTTP Basic Auth oder ein Query-Parameter, funktionieren gleich, ob eine Anfrage direkt von einem mobilen Client stammt oder von Ihrem eigenen Backend, das den Aufruf weiterleitet. Diese Entscheidung (clientseitig oder serverseitig) schränkt also in keinem Fall ein, welcher Authentifizierungsstil verfügbar ist. Die Kontingentnutzung ist in jeder Antwort über Header wie X-Quota-Used und X-Quota-Reset sichtbar, dokumentiert unter /docs/rate-limits/, was nützlich ist, um den Fortschritt der Einführung bei einer mobilen Migration zu überwachen, sofern Sie an der Stelle, von der die Anfragen ausgehen, auf diese Header zugreifen können.
Mobile Migrationen belohnen Geduld mehr als serverseitige, vor allem weil der Veröffentlichungs- und Verbreitungszyklus einen Zeitplan vorgibt, den Sie durch schnelleres Arbeiten nicht verkürzen können. Wer von Anfang an ein längeres Übergangsfenster einplant, erspart sich den Frust, das Tempo einer serverseitigen Migration von einem Prozess zu erwarten, der strukturell nicht so schnell sein kann.