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 une intégration côté serveur sans toucher au client
L'une des propriétés les plus agréables d'une architecture backend bien conçue est qu'une migration de fournisseur peut se faire entièrement derrière une frontière d'API interne, invisible pour les clients web ou mobiles qui consomment votre service. Y parvenir dépend moins du fournisseur vers lequel vous migrez que de l'existence, déjà propre, de cette frontière dans votre code avant le début de la migration.
Le principe de conception clé est que les applications clientes (front-ends web, applications mobiles, autres services internes) doivent communiquer avec votre propre API, qui renvoie votre propre format de réponse normalisé, plutôt que de communiquer directement avec un fournisseur de géocodage tiers ou de recevoir telle quelle la réponse brute de ce fournisseur. Lorsque cette frontière existe, une migration de fournisseur ne touche que l'implémentation derrière votre propre endpoint, et tous les consommateurs de cet endpoint sont épargnés par construction, et non par chance.
Si cette frontière n'existe pas encore, c'est-à-dire si les clients reçoivent actuellement le format de réponse brut d'un fournisseur précis, une migration est un bon moment pour l'introduire, même si cela ajoute un peu de travail au départ. Les étapes ressemblent à peu près à ceci :
- Définissez votre propre format de réponse normalisé, en choisissant des noms de champs qui ont du sens pour votre application plutôt que de recopier mot pour mot les conventions d'un fournisseur précis
- Construisez la correspondance interne entre la réponse réelle du fournisseur actuel et ce format normalisé, et mettez à jour chaque client pour qu'il consomme le format normalisé au lieu de la réponse brute du fournisseur
- Une fois que chaque client a été mis à jour vers le format normalisé et déployé, la migration de fournisseur proprement dite derrière cette frontière devient une modification purement backend, sans aucune coordination nécessaire avec les clients
C'est réellement plus de travail la première fois, mais cela porte ses fruits à chaque migration suivante, puisque l'étape 3 devient la seule nécessaire pour tout changement futur de fournisseur.
Comme les hôtes compatibles de My Geocode conservent le format de réponse exact d'un fournisseur familier, les équipes qui n'ont pas encore construit cette couche de normalisation peuvent utiliser un hôte compatible comme étape intermédiaire, sans réécrire le code de correspondance existant, et gagner ainsi du temps pour construire correctement la couche de normalisation plus tard, sans qu'une échéance urgente n'impose d'en bâcler une version maintenant. La présentation des hôtes compatibles couvre l'ensemble des hôtes disponibles.
L'authentification du service backend lui-même accepte un en-tête X-API-Key, un en-tête Authorization: Bearer, l'authentification HTTP Basic ou un paramètre de requête, selon ce qui s'accorde le plus naturellement avec les conventions de requêtes sortantes existantes de votre backend, et la consommation du quota est visible dans les en-têtes de réponse de chaque appel, documentés sur /docs/rate-limits/, que votre backend peut surveiller de façon centralisée sans qu'aucun client n'ait besoin de savoir que la notion de quota existe.
Une migration côté serveur invisible pour les clients n'est pas une astuce particulière : c'est simplement le résultat naturel d'une architecture dotée d'une véritable frontière déjà en place. Construire cette frontière, même sous la pression d'une migration, vaut l'investissement précisément parce qu'elle supprime la coordination avec les clients pour toutes les migrations suivantes.