Migrar una automatización de Zapier o Make a un nuevo host de geocodificación
Las automatizaciones sin código basadas en un paso de geocodificación necesitan un enfoque de migración distinto al del código propio. Así puedes gestionar ese cambio.
Dejar una integración de zona horaria de Google Maps Platform
Una consulta de zona horaria rara vez tiene su propia línea en las notas de arquitectura de un proyecto. Normalmente va incluida dentro de una cuenta de Google Maps Platform configurada para la geocodificación o la visualización de mapas, y se llama desde donde haga falta convertir una marca de tiempo a la hora local de una coordenada determinada. Esa agrupación es precisamente lo que hace un poco incómodo moverla por separado: la cuenta, la facturación y la clave se comparten con funciones que quizá no estés migrando al mismo tiempo.
La API de zona horaria de Google recibe una ubicación y una marca de tiempo y devuelve un timeZoneId, un timeZoneName y valores de desfase en segundos tanto para la hora estándar como para cualquier ajuste de horario de verano. Es una respuesta pequeña y bien definida, lo que la convierte en una primera candidata razonable para separarla de una cuenta de Google más grande antes de abordar la geocodificación o algo más complejo.
My Geocode ofrece las consultas de zona horaria como un endpoint independiente y totalmente funcional, y no como una capa que imita el formato concreto de Google, ya que esta es una de las consultas en las que se puede describir directamente una respuesta real que funciona. Una solicitud para una coordenada devuelve el identificador de zona horaria y la información de desfase necesarios para convertir una marca de tiempo UTC a la hora local. Los detalles están en /docs/timezone-lookup/.
Como se trata de un endpoint independiente y no de un host de compatibilidad equivalente, dejar la API de zona horaria de Google implica ajustar los nombres de campo concretos que lee tu código, lo que normalmente es un cambio pequeño y acotado, ya que los datos de zona horaria ocupan por naturaleza poco: un identificador, un desfase y quizá un indicador de horario de verano. Esto supone bastante menos trabajo que migrar una integración de geocodificación completa con su análisis de los componentes de la dirección.
Pasos prácticos para este cambio concreto:
- Aísla cada punto del código que llama actualmente al endpoint de zona horaria de Google, ya que a menudo se llama solo desde una o dos funciones de utilidad, incluso en un código grande
- Prueba con coordenadas de regiones con reglas de zona horaria poco habituales, como lugares con desfases de media hora o zonas sin horario de verano, ya que es en estos casos límite donde suelen fallar las conversiones ingenuas
- Actualiza la autenticación a una clave enviada como
X-API-Key,Authorization: Bearer, autenticación HTTP Basic o un parámetro de consulta, la opción que encaje de forma más natural con tu código de solicitudes actual
Aquí el precio es el mismo que el de cualquier otro endpoint: 2.500 solicitudes gratuitas al día sin clave, 2.500 gratuitas más por clave y por día, contadas por red, y después crédito prepago a 0,0001 € por solicitud o una clave Unlimited a 50 € al mes. Si el uso de Google Maps Platform de tu cuenta eran sobre todo llamadas de zona horaria con alguna geocodificación ocasional, mover solo la parte de zona horaria puede reducir considerablemente lo que sigue ligado a la cuenta original, y el resto de la migración puede seguir a su propio ritmo.