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.
Señales de alerta de que estás atado a un formato propietario
La dependencia de un proveedor rara vez llega con una sola decisión. Se acumula poco a poco, un atajo cómodo tras otro, hasta que un código que empezó como una integración razonable con un proveedor se ha vuelto, sin que nadie lo note, difícil de separar de ese proveedor. Conviene reconocer algunos patrones concretos como señales de alerta, porque cada uno por separado parece inofensivo cuando ocurre.
Los nombres exactos de los campos de un proveedor se usan en todo tu propio modelo de datos. Si el esquema de tu base de datos, las respuestas de tu API interna y tu código de front-end usan todos la nomenclatura de campos de un proveedor concreto, formatted_address o display_name o como sea que ese proveedor lo llame, en lugar de tu propia nomenclatura traducida una sola vez en la frontera, cada capa de tu aplicación ha absorbido una dependencia de las convenciones de ese único proveedor.
Las peculiaridades de un proveedor se han sorteado en la lógica de negocio, no aisladas en la frontera de la integración. Si una solución provisional para una peculiaridad concreta en la forma en que un proveedor formatea una dirección de caso límite vive dentro de la lógica de negocio general y no dentro de la función acotada que habla con ese proveedor, migrar implica localizar y desenredar esa solución provisional de un código que, a primera vista, no tiene nada que ver con la geocodificación.
Nadie puede responder rápidamente en cuántos lugares del código se menciona al proveedor por su nombre. Si responder "dónde dependemos de este proveedor" requiere una auditoría minuciosa en lugar de una respuesta rápida y segura, esa incertidumbre es en sí misma una señal de dependencia, ya que significa que la dependencia se ha extendido más allá de lo que nadie ha estado controlando activamente.
Los tipos de objeto específicos de la biblioteca cliente se usan como firmas de funciones en otras partes del código. Si funciones que no tienen relación con la geocodificación aceptan como parámetro el tipo de respuesta del SDK de un proveedor concreto, el sistema de tipos de ese proveedor se ha convertido de hecho en parte del sistema de tipos de tu propia aplicación, y eliminarlo exige tocar cada función que lo referencia, no solo el código de geocodificación.
Nunca se ha probado una migración, ni siquiera parcialmente, en los años que lleva activa la integración. Una integración que en teoría podría pasar a otro proveedor pero que nunca se ha probado realmente con uno no es, en la práctica, muy distinta de una que no puede moverse en absoluto, hasta que alguien la prueba de verdad.
Ninguno de estos patrones es catastrófico por sí solo, y la mayoría de las integraciones presentan al menos uno de ellos sin consecuencias reales durante mucho tiempo. El valor de reconocerlos está en poder hacer de la dependencia una concesión deliberada y aceptable, en lugar de una accidental que nadie eligió. A veces la comodidad compensa el acoplamiento, sobre todo en un proyecto pequeño en el que una migración completa costaría más tiempo de ingeniería de lo que vale la flexibilidad. El problema solo surge cuando la dependencia se produce de forma invisible y se descubre en el peor momento posible, durante una migración forzada con una fecha límite, en lugar de reconocerse y aceptarse a propósito de antemano.
Si ya existe un host compatible para el proveedor del que dependes actualmente, parte de este riesgo es naturalmente menor, ya que 17 hosts compatibles significan que al menos una vía probable de migración no requiere desenredar ninguna dependencia a nivel de campos, solo un cambio de host y de clave. Es un seguro razonable que tener preparado incluso para una integración que no tienes previsto mover de inmediato.