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.
Eine serverseitige Integration migrieren, ohne den Client anzufassen
Eine der angenehmeren Eigenschaften einer gut gestalteten Backend-Architektur ist, dass eine Anbietermigration vollständig hinter einer internen API-Grenze stattfinden kann, unsichtbar für jeden Web- oder Mobil-Client, der Ihren Dienst nutzt. Ob das gelingt, hängt weniger vom konkreten Zielanbieter ab als davon, ob diese Grenze vor Beginn der Migration bereits sauber in Ihrer Codebasis existiert.
Das zentrale Gestaltungsprinzip lautet: Client-Anwendungen (Web-Frontends, mobile Apps, andere interne Dienste) sollten mit Ihrer eigenen API sprechen, die Ihre eigene normalisierte Antwortform zurückgibt, statt direkt mit einem externen Geokodierungsanbieter zu sprechen oder dessen rohe Antwortform unverändert durchgereicht zu bekommen. Wenn diese Grenze existiert, betrifft eine Anbietermigration nur die Implementierung hinter Ihrem eigenen Endpunkt, und jeder Nutzer dieses Endpunkts bleibt konstruktionsbedingt unberührt, nicht durch Glück.
Wenn diese Grenze noch nicht existiert, Clients also derzeit das rohe Antwortformat eines bestimmten Anbieters erhalten, ist eine Migration ein guter Moment, sie einzuführen, auch wenn das anfangs etwas Mehrarbeit bedeutet. Die Schritte sehen ungefähr so aus:
- Definieren Sie Ihr eigenes normalisiertes Antwortformat und wählen Sie Feldnamen, die für Ihre Anwendung sinnvoll sind, statt die Konventionen eines bestimmten Anbieters wörtlich zu übernehmen
- Bauen Sie die interne Zuordnung von der tatsächlichen Antwort des aktuellen Anbieters in dieses normalisierte Format und stellen Sie jeden Client so um, dass er das normalisierte Format statt der rohen Anbieterantwort verarbeitet
- Sobald jeder Client auf das normalisierte Format umgestellt und ausgerollt ist, wird die eigentliche Anbietermigration hinter dieser Grenze zu einer reinen Backend-Änderung, die überhaupt keine Abstimmung mit den Clients erfordert
Das ist beim ersten Mal tatsächlich mehr Arbeit, zahlt sich aber bei jeder folgenden Migration aus, da Schritt 3 dann der einzige Schritt ist, der für einen künftigen Anbieterwechsel nötig ist.
Da die Kompatibilitätshosts von My Geocode die exakte Antwortform eines bekannten Anbieters beibehalten, können Teams, die diese Normalisierungsschicht noch nicht gebaut haben, einen Kompatibilitätshost als Zwischenschritt nutzen, der keine Neufassung des bestehenden Zuordnungscodes erfordert. So gewinnen sie Zeit, die Normalisierungsschicht später ordentlich zu bauen, ohne dass eine dringende Frist jetzt eine überhastete Version erzwingt. Die Übersicht der Kompatibilitätshosts zeigt alle verfügbaren Hosts.
Die Authentifizierung für den Backend-Dienst selbst unterstützt einen X-API-Key-Header, einen Authorization: Bearer-Header, HTTP Basic Auth oder einen Query-Parameter, je nachdem, was am natürlichsten zu den bestehenden Konventionen Ihres Backends für ausgehende Anfragen passt. Die Kontingentnutzung ist bei jedem Aufruf über Antwort-Header sichtbar, dokumentiert unter /docs/rate-limits/, und Ihr Backend kann sie zentral überwachen, ohne dass irgendein Client überhaupt wissen muss, dass es ein Kontingent gibt.
Eine für Clients unsichtbare serverseitige Migration ist kein besonderer Trick, sondern einfach die natürliche Folge einer Architektur, in der bereits eine ordentliche Grenze besteht. Diese Grenze zu bauen, selbst unter Migrationsdruck, ist die Investition wert, gerade weil sie die Abstimmung mit Clients aus jeder künftigen Migration entfernt.