Migrer une automatisation Zapier ou Make vers un nouvel hôte de géocodage
Les automatisations sans code construites autour d'une étape de géocodage demandent une autre approche de migration que le code sur mesure. Voici comment gérer ce changement.
Migrer les appels de géocodage d'une application mobile
Migrer des appels de géocodage effectués directement depuis une application mobile impose quelques contraintes qu'une migration purement côté serveur n'a pas à gérer, et il vaut la peine de les nommer clairement avant de commencer, car elles modifient la forme du plan.
La première est le rythme des publications. Une modification côté serveur peut être mise en ligne dès son déploiement. Une modification d'application mobile doit passer par la validation de la boutique d'applications, puis son adoption dépend de la mise à jour effective par les utilisateurs, ce qui, pour de nombreuses applications, prend des semaines avant d'atteindre la majorité des installations et peut prendre bien plus longtemps pour atteindre tout le monde. Tout plan de migration pour une application mobile doit prévoir de faire fonctionner deux fournisseurs, ou deux versions de l'application, en parallèle plus longtemps que ne l'exige généralement une migration côté serveur.
La seconde est l'exposition des identifiants. Une clé d'API intégrée directement dans le binaire d'une application mobile peut être extraite par quiconque est assez motivé pour chercher, ce qui constitue un enjeu de sécurité quel que soit le fournisseur concerné. Si votre intégration actuelle appelle une API de géocodage directement depuis le client avec une clé intégrée, une migration est un bon moment pour reconsidérer ce modèle et placer plutôt l'appel derrière votre propre backend, même si cela ajoute un peu de latence et un peu de travail côté backend.
Quelques étapes pratiques qui s'appliquent à la plupart des migrations mobiles :
- Si vous déplacez l'appel côté serveur, concevez d'abord le nouvel endpoint de votre backend et faites communiquer l'application mobile avec votre propre API avant de vous soucier du fournisseur qui se trouve derrière, afin de dissocier entièrement la modification côté application de la modification côté fournisseur
- Si vous gardez l'appel côté client, utilisez une valeur de configuration définie à la compilation pour l'hôte de l'API et la clé plutôt que de les coder en dur, afin qu'une future migration n'oblige pas à rechercher et remplacer à nouveau une chaîne littérale dans tout le code
- Testez sur les anciennes versions de l'application encore réellement utilisées, et pas seulement sur la dernière version, si vous prévoyez de prendre en charge les deux fournisseurs pendant une période de transition, car une ancienne version de l'application qui appelle un ancien hôte bientôt retiré est un scénario réaliste qui mérite une décision explicite sur la durée pendant laquelle continuer à le prendre en charge
Les options d'authentification de My Geocode (un en-tête X-API-Key, un en-tête Authorization: Bearer, l'authentification HTTP Basic ou un paramètre de requête) fonctionnent de la même manière, que la requête provienne directement d'un client mobile ou de votre propre backend servant de proxy, de sorte que ce choix particulier (côté client ou côté serveur) ne limite dans aucun cas le mode d'authentification disponible. La consommation du quota est visible sur chaque réponse grâce à des en-têtes comme X-Quota-Used et X-Quota-Reset, documentés sur /docs/rate-limits/, ce qui est utile pour suivre l'avancement du déploiement d'une migration mobile si vous pouvez accéder à ces en-têtes depuis l'endroit d'où partent les requêtes.
Les migrations mobiles récompensent la patience davantage que les migrations côté serveur, principalement parce que le cycle de publication et d'adoption impose un calendrier que vous ne pouvez pas raccourcir en travaillant plus vite. Prévoir dès le départ une fenêtre de transition plus longue évite la frustration d'attendre le rythme d'une migration côté serveur d'un processus qui, par nature, ne peut pas avancer aussi vite.