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.
Quitter une intégration de fuseau horaire Google Maps Platform
Une recherche de fuseau horaire a rarement sa propre ligne dans les notes d'architecture d'un projet. Elle s'intègre généralement à un compte Google Maps Platform créé pour le géocodage ou l'affichage de cartes, et elle est appelée partout où un horodatage doit être converti en heure locale pour une coordonnée donnée. C'est précisément ce regroupement qui rend sa migration isolée un peu délicate : le compte, la facturation et la clé sont tous partagés avec des fonctionnalités que vous ne migrez peut-être pas en même temps.
L'API de fuseau horaire de Google prend une position et un horodatage et renvoie un timeZoneId, un timeZoneName et des valeurs de décalage en secondes, à la fois pour l'heure standard et pour tout ajustement lié à l'heure d'été. C'est une réponse petite et bien définie, ce qui en fait une première candidate raisonnable à détacher d'un compte Google plus large avant de s'attaquer au géocodage ou à quoi que ce soit de plus complexe.
My Geocode propose la recherche de fuseau horaire comme un endpoint indépendant et pleinement fonctionnel, plutôt que comme une couche qui reproduit le format spécifique de Google, car c'est l'une des recherches pour lesquelles une vraie réponse fonctionnelle peut être décrite directement. Une requête pour une coordonnée renvoie l'identifiant de fuseau horaire et les informations de décalage nécessaires pour convertir un horodatage UTC en heure locale. Les détails se trouvent sur /docs/timezone-lookup/.
Comme il s'agit d'un endpoint autonome et non d'un hôte de compatibilité équivalent, quitter l'API de fuseau horaire de Google implique d'ajuster les noms de champs précis que lit votre code, ce qui est normalement une modification petite et bien délimitée, car les données de fuseau horaire sont par nature peu volumineuses : un identifiant, un décalage, éventuellement un indicateur d'heure d'été. C'est nettement moins de travail que la migration d'une intégration de géocodage complète avec son analyse des composants d'adresse.
Étapes pratiques pour cette migration :
- Isolez chaque point d'appel qui sollicite actuellement l'endpoint de fuseau horaire de Google, car il est souvent appelé depuis une ou deux fonctions utilitaires seulement, même dans un code volumineux
- Testez sur des coordonnées situées dans des régions aux règles de fuseau horaire inhabituelles, comme les lieux qui appliquent des décalages d'une demi-heure ou les zones sans heure d'été, car c'est dans ces cas limites que les conversions naïves ont tendance à échouer
- Passez l'authentification à une clé envoyée via
X-API-Key,Authorization: Bearer, l'authentification HTTP Basic ou un paramètre de requête, selon ce qui s'intègre le plus naturellement à votre code de requête existant
La tarification est ici la même que pour tous les autres endpoints : 2 500 requêtes gratuites par jour sans clé, 2 500 de plus gratuites par clé et par jour, comptées par réseau, puis du crédit prépayé à 0,0001 € par requête ou une clé Unlimited à 50 € par mois. Si l'utilisation de Google Maps Platform sur votre compte consistait surtout en appels de fuseau horaire avec un géocodage occasionnel, déplacer uniquement la partie fuseau horaire peut réduire sensiblement ce qui reste lié au compte d'origine, et le reste de la migration peut suivre à son propre rythme.