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 una integración del lado del servidor sin tocar el cliente
Una de las propiedades más agradables de una arquitectura de backend bien diseñada es que la migración de proveedor puede hacerse por completo detrás de una frontera de API interna, invisible para cualquier cliente web o móvil que consuma tu servicio. Lograrlo depende menos del proveedor concreto al que migras y más de si esa frontera ya existe de forma limpia en tu código antes de empezar la migración.
El principio de diseño clave es que las aplicaciones cliente (front ends web, apps móviles, otros servicios internos) se comuniquen con tu propia API, que devuelve tu propia forma de respuesta normalizada, en lugar de hablar directamente con un proveedor de geocodificación externo o recibir la respuesta en bruto de ese proveedor tal cual. Cuando esa frontera existe, una migración de proveedor solo afecta a la implementación detrás de tu propio endpoint, y ningún consumidor de ese endpoint se ve afectado, por diseño y no por suerte.
Si esa frontera aún no existe, es decir, si los clientes reciben actualmente el formato de respuesta en bruto de un proveedor concreto, una migración es un buen momento para introducirla, aunque suponga algo de trabajo extra al principio. Los pasos son más o menos estos:
- Define tu propio formato de respuesta normalizado, con nombres de campo que tengan sentido para tu aplicación en lugar de copiar al pie de la letra las convenciones de un proveedor concreto
- Construye la correspondencia interna entre la respuesta real del proveedor actual y ese formato normalizado, y actualiza cada cliente para que consuma el formato normalizado en lugar de la respuesta en bruto del proveedor
- Una vez que todos los clientes estén actualizados al formato normalizado y desplegados, la migración real de proveedor detrás de esa frontera se convierte en un cambio solo de backend, sin ninguna coordinación con los clientes
Esto supone realmente más trabajo la primera vez, pero compensa en cada migración posterior, ya que el paso 3 se convierte en el único necesario para cualquier cambio de proveedor futuro.
Como los hosts compatibles de My Geocode conservan la forma de respuesta exacta de un proveedor conocido, los equipos que aún no han construido esta capa de normalización pueden usar un host compatible como paso intermedio que no requiere reescribir el código de correspondencia existente, y así ganar tiempo para construir la capa de normalización como es debido más adelante, sin un plazo urgente que obligue a hacer ahora una versión precipitada. La descripción general de los hosts compatibles recoge el conjunto completo disponible.
La autenticación para el propio servicio de backend admite una cabecera X-API-Key, una cabecera Authorization: Bearer, autenticación HTTP Basic o un parámetro de consulta, lo que mejor encaje con las convenciones de solicitudes salientes que ya usa tu backend, y el uso de la cuota es visible en las cabeceras de respuesta de cada llamada, documentadas en /docs/rate-limits/, que tu backend puede supervisar de forma centralizada sin que ningún cliente tenga que saber siquiera que la cuota existe como concepto.
Una migración de servidor invisible para los clientes no es un truco especial; es simplemente el resultado natural de una arquitectura que ya tiene una frontera adecuada. Construir esa frontera, incluso bajo la presión de una migración, merece la inversión precisamente porque elimina la coordinación con los clientes en todas las migraciones posteriores a esta.