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.
Actualizar bibliotecas cliente y SDK durante una migración
Muchas integraciones de geocodificación y de datos de ubicación no se comunican directamente con una API HTTP; pasan por una biblioteca cliente oficial o un SDK que envuelve las solicitudes, gestiona la autenticación y devuelve los resultados como objetos tipados en el lenguaje en que esté escrita la aplicación. Esa capa adicional es cómoda en el día a día, pero añade una complicación real a una migración, porque la propia biblioteca, y no solo la API que hay detrás, tiene que formar parte del plan.
A grandes rasgos, una migración que implica una biblioteca cliente suele seguir uno de tres caminos, y vale la pena decidir cuál se aplica antes de empezar:
La biblioteca admite una URL base personalizada. Algunas bibliotecas cliente oficiales están escritas con la flexibilidad suficiente para aceptar una URL base distinta para las solicitudes sin cambiar el resto de su interfaz; en ese caso, apuntar la biblioteca existente a un host compatible, si la estructura de respuesta coincide con lo que la biblioteca espera analizar, puede funcionar prácticamente sin cambios en el código de la aplicación. Es el mejor caso y lo primero que conviene comprobar.
La biblioteca está estrechamente ligada a un solo host. Muchas bibliotecas cliente tienen su host de destino escrito en el código o hacen suposiciones específicas del flujo de autenticación de su proveedor que no se pueden redirigir fácilmente. En este caso, el camino pragmático suele ser prescindir por completo de la biblioteca para las llamadas migradas y hacer las solicitudes directamente a la API del nuevo proveedor, sustituyendo el envoltorio tipado de la biblioteca por tu propia función de solicitud sencilla.
No hay ninguna biblioteca de por medio. Si tu integración ya hace solicitudes HTTP directas sin una biblioteca oficial en medio, toda esta cuestión no se aplica, y la migración consiste más directamente en cambiar el host, la clave y cualquier análisis de respuestas que haya que ajustar.
Como la autenticación de My Geocode admite un encabezado X-API-Key, un encabezado Authorization: Bearer, autenticación HTTP Basic o un parámetro de consulta, una biblioteca cliente que ya se autentique de alguna de estas formas habituales tiene bastantes posibilidades de funcionar con un host compatible con solo cambiar la URL base y usar una clave nueva, incluso sin una biblioteca oficial propia para esta plataforma concreta. Vale la pena probarlo directamente en un entorno de pruebas antes de suponer que funcionará sin cambios o que no funcionará en absoluto; el resultado real depende por completo de la flexibilidad con que esté escrita la biblioteca en cuestión.
Sea cual sea el camino, conviene documentar la decisión de forma explícita en tus notas de migración, ya que una dependencia de biblioteca que se deja de usar discretamente durante una migración sin documentarlo suele confundir a quien mantenga el código un año después, cuando actualice la biblioteca antigua esperando que siga formando parte del flujo de solicitudes. Un breve comentario que explique que las solicitudes ya no pasan por la biblioteca cliente oficial, y por qué, evita confusiones reales más adelante.