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.
Relacionar los códigos de error entre proveedores antes de cambiar
En una migración, las respuestas correctas reciben casi toda la atención, ya que son lo que muestra una demo y lo que suele comprobar una primera ronda de pruebas. Las respuestas de error reciben mucha menos atención, y eso es justo al revés de lo que debería ser, porque el código de gestión de errores suele ser lo primero que falla, y de la forma más visible, en producción cuando un proveedor cambia por debajo de una aplicación.
Cada proveedor de geocodificación y de datos de ubicación tiene sus propias convenciones para señalar un fallo: algunos usan exclusivamente códigos de estado HTTP, otros incluyen un campo de estado dentro de una respuesta JSON que por lo demás tiene estado 200, algunos distinguen entre «no se encontraron resultados» y «solicitud no válida» con códigos diferentes, y otros agrupan ambos en un error genérico. La lógica de reintentos de una aplicación, los mensajes de error que ven los usuarios y las alertas de monitorización suelen construirse en torno a las convenciones de error de un proveedor concreto, a veces sin que nadie documente esa dependencia de forma explícita.
Antes de cambiar de proveedor, conviene construir una tabla de correspondencia explícita entre las respuestas de error del proveedor anterior y las del nuevo, que cubra como mínimo:
- Ningún resultado encontrado para una consulta válida pero sin coincidencias, a diferencia de una solicitud mal formada o no válida
- Límite de frecuencia superado, y si la respuesta incluye alguna información sobre cuándo reintentar
- Fallos de autenticación, incluidas credenciales caducadas, ausentes o mal formadas
- Errores del servidor por parte del proveedor, a diferencia de los errores de solicitud del cliente
- Cualquier valor de estado específico del proveedor que tu código compruebe explícitamente por nombre o número
My Geocode documenta sus respuestas de error y sus convenciones de estado en /docs/errors/, y cada respuesta incluye además cabeceras de cuota, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining, X-Quota-Network-Used, X-Credits-Remaining, X-Key-IPs-Used, X-Key-IPs-Limit y X-Quota-Reset, que cubren una categoría de información (estado de cuota y de frecuencia) que algunos proveedores esconden dentro del cuerpo de las respuestas de error en lugar de exponerla directamente en cabeceras. Comprobar si tu lógica de reintentos actual lee la información de cuota del cuerpo de la respuesta o de una cabecera es un punto concreto que conviene añadir a una lista de verificación de migración, ya que la información de cuota en cabeceras suele ser más fácil de leer sin tocar la ruta de análisis de la respuesta que se usa para los datos reales.
Una forma práctica de construir la tabla de correspondencia es provocar deliberadamente cada condición de error contra el proveedor anterior y el nuevo en un entorno de pruebas, en lugar de confiar solo en la documentación, ya que la documentación y el comportamiento real no siempre coinciden exactamente, en ningún proveedor. Envía una solicitud mal formada, agota deliberadamente una pequeña cuota de prueba y envía una clave no válida, y luego anota exactamente qué devuelve cada proveedor en cada caso.
Este tipo de trabajo de correspondencia de errores rara vez aparece en el plan de proyecto de una migración porque no produce una función visible, pero es desproporcionadamente responsable de cómo se recuerda una migración después. Una migración que cambia limpiamente las respuestas correctas pero deja rota la gestión de errores suele generar muchos más tickets de soporte en las primeras semanas tras el cambio que una que solo acertó en parte con el camino feliz.