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.
Migrar las llamadas de geocodificación de una app móvil
Migrar las llamadas de geocodificación que se hacen directamente desde una app móvil introduce algunas restricciones que una migración puramente del lado del servidor no tiene, y conviene nombrarlas con claridad antes de empezar, ya que cambian la forma del plan.
La primera es el ritmo de publicación. Un cambio en el servidor puede entrar en producción en cuanto se despliega. Un cambio en una app móvil tiene que pasar la revisión de la tienda de aplicaciones, y su adopción depende de que los usuarios actualicen de verdad, lo que en muchas apps tarda semanas en llegar a la mayoría de las instalaciones y puede tardar bastante más en llegar a todos. Cualquier plan de migración para una app móvil debe contemplar mantener dos proveedores, o dos versiones de la app, en paralelo durante más tiempo del que suele requerir una migración de servidor.
La segunda es la exposición de credenciales. Cualquiera con motivación para buscarla puede extraer una clave de API incrustada directamente en el binario de una app móvil, lo que es una cuestión de seguridad sea cual sea el proveedor. Si tu integración actual llama a una API de geocodificación directamente desde el cliente con una clave incrustada, una migración es un buen momento para replantearte ese patrón y mover la llamada detrás de tu propio backend, aunque eso añada algo de latencia y algo de trabajo en el backend.
Algunos pasos prácticos que se aplican a la mayoría de las migraciones móviles:
- Si trasladas la llamada al servidor, diseña primero el nuevo endpoint del backend y haz que la app móvil se comunique con tu propia API antes de preocuparte por qué proveedor está detrás, desacoplando por completo el cambio en la app del cambio de proveedor
- Si mantienes la llamada en el cliente, usa un valor de configuración en tiempo de compilación para el host y la clave de la API en lugar de escribirlos directamente en el código, para que una futura migración no obligue de nuevo a buscar y reemplazar una cadena literal en todo el código
- Prueba con versiones antiguas reales de la app que siguen en uso, no solo con la última compilación, si piensas admitir ambos proveedores durante un periodo de transición, ya que una versión antigua de la app que llama a un host antiguo a punto de retirarse es un escenario realista que merece una decisión explícita sobre cuánto tiempo seguir dándole soporte
Las opciones de autenticación de My Geocode (una cabecera X-API-Key, una cabecera Authorization: Bearer, autenticación HTTP Basic o un parámetro de consulta) funcionan igual tanto si la solicitud parte directamente de un cliente móvil como de tu propio backend haciendo de proxy, así que esta decisión concreta (cliente frente a servidor) no limita el estilo de autenticación disponible en ningún caso. El uso de la cuota es visible en cada respuesta mediante cabeceras como X-Quota-Used y X-Quota-Reset, documentadas en /docs/rate-limits/, lo que resulta útil para seguir el avance del despliegue de una migración móvil si puedes acceder a esas cabeceras desde donde se originan las solicitudes.
Las migraciones móviles recompensan la paciencia más que las del lado del servidor, sobre todo porque el ciclo de publicación y adopción impone un calendario que no puedes comprimir trabajando más rápido. Planificar desde el principio una ventana de transición más larga evita la frustración de esperar el ritmo de una migración de servidor en un proceso que, por su propia estructura, no puede avanzar tan deprisa.