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.
Diferencias en los límites de frecuencia que debes esperar al cambiar de proveedor
Los límites de frecuencia difieren entre proveedores de formas que van más allá del número bruto de solicitudes permitidas, y una migración que solo compruebe el límite principal puede pasar por alto diferencias estructurales que en la práctica importan más que la propia cifra.
Algunas dimensiones estructurales que conviene comprobar específicamente en cualquier proveedor al que te cambies o del que te vayas:
Sobre qué se cuenta el límite. Algunos proveedores limitan solo por clave de API. Otros limitan por dirección IP, por cuenta o por alguna combinación. La estructura de My Geocode cuenta la cuota gratuita por red, es decir, por /24 en IPv4 o por /48 en IPv6, y se comparte entre el uso sin clave y con clave que procede de esa misma red. Es un modelo bastante distinto de un límite contado solo por clave, y afecta especialmente a las aplicaciones que funcionan detrás de un rango de IP compartido, como una red corporativa o un entorno en la nube donde muchas instancias comparten un bloque de direcciones.
Cómo se reinicia el límite. Diario, mensual o con una ventana móvil son enfoques habituales, y la diferencia influye en cómo deberías plantear el ritmo de un proceso masivo o la gestión de un pico de tráfico. Un límite que se reinicia en un corte diario fijo se comporta de forma distinta ante una ráfaga de tráfico que uno basado en una ventana móvil.
Si la información del límite aparece en cada respuesta o requiere una comprobación aparte. Esto determina si tu aplicación puede autorregular su ritmo de forma proactiva o si solo descubrirá que ha alcanzado un límite cuando falle una solicitud. My Geocode lo expone directamente: cada respuesta incluye como cabeceras 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, documentadas en /docs/rate-limits/, lo que significa que la lógica de reintentos y de ritmo puede leer el estado actual de la misma respuesta que acaba de recibir en lugar de consultar periódicamente un endpoint o un panel aparte.
Qué ocurre al superar el límite. ¿El proveedor detiene en seco las solicitudes, pasa a respuestas más lentas o factura automáticamente el excedente? El modelo de My Geocode más allá de la cuota diaria gratuita es crédito prepago a 0,0001 € por solicitud o una clave Unlimited a 50 € al mes, con todos los endpoints al mismo precio, algo que conviene comparar directamente con el comportamiento de excedente o de limitación que use tu proveedor actual, ya que pueden diferir de forma importante en cómo afecta realmente un pico de tráfico al comportamiento de tu aplicación en ese momento.
Antes de cambiar, conviene reescribir de forma explícita cualquier lógica de reintentos o de espera progresiva que haga referencia a un nombre de cabecera, un código de estado o un umbral numérico concretos de tu proveedor actual, en lugar de suponer que la misma lógica funcionará sin más con las señales de límite de frecuencia de otro proveedor. En la mayoría de las aplicaciones es un fragmento pequeño de código, pero es exactamente el tipo de detalle que se rompe en silencio durante una migración si no se revisa de forma deliberada, ya que un error de límite de frecuencia mal gestionado suele empeorar un pico de tráfico real en lugar de mejorarlo.