El problema de las claves de API que nunca caducan
Una clave emitida hace años, que nunca se ha rotado y que hoy sigue siendo válida, no es una comodidad. Es un riesgo que nadie ha revisado de verdad en años.
Por qué una migración debería llevar una tarde y no un trimestre
Un proyecto de migración al que se le asigna un trimestre de ingeniería para cambiar de proveedor de datos de ubicación no suele ser un trimestre de trabajo realmente necesario. Es un trimestre de trabajo creado por decisiones de diseño tomadas años antes: un formato de respuesta propietario que hay que desmontar campo por campo, un SDK cuyas llamadas a métodos están dispersas por el código en lugares que nadie documentó, una gestión de errores construida en torno a los códigos de estado específicos de un proveedor. Nada de esa complejidad es inherente a la idea de consultar una dirección o una IP. Toda ella se hereda de decisiones que hicieron cómoda la integración original a costa de encarecer una migración futura.
Creamos 17 hosts compatibles precisamente para que ese trimestre sea innecesario para cualquiera cuya integración existente ya hable uno de esos formatos de proveedor. Si tu código llama al endpoint de una API de geocodificación o de IP conocida y analiza su formato de respuesta específico, apuntar ese mismo código a nuestro host compatible correspondiente debería requerir cambiar una URL base y una clave de API, no reescribir la lógica de análisis que lleva años funcionando bien. La autenticación acepta una clave como cabecera, como token bearer, con autenticación HTTP Basic o como parámetro de consulta, así que el patrón que ya use tu código muy probablemente ya está admitido.
Una migración en una tarde no es algo que afirmemos a la ligera, porque sabemos exactamente cuánto esfuerzo nos costó hacerlo realidad: igualar campo por campo la forma de respuesta de otro proveedor, probarla con solicitudes reales y mantener esa forma estable para que el código existente de un cliente no tenga motivos para notar ninguna diferencia más allá de adónde va la solicitud. Ese trabajo lo asumimos nosotros por adelantado precisamente para que no tenga que repetirse, más adelante, en el código de cada cliente que quiera comprobar si merece la pena cambiar.
La idea de fondo va más allá de nuestros propios hosts compatibles: una migración que lleva un trimestre es información de diagnóstico sobre la integración anterior, no una propiedad natural de cambiar de proveedor en general. Si dejar un proveedor requiere un proyecto de varios meses, alguien, en algún lugar, se benefició de que existiera esa fricción, se construyera deliberadamente para crearla o no. Un proveedor realmente seguro de sus datos, sus precios y su fiabilidad no tiene motivos para dificultar que te vayas, porque todo su argumento debería ser que un cliente que lo pruebe no querrá irse, no que irse sea demasiado caro para intentarlo.
Preferimos competir en si el producto merece que te quedes, evaluado con honestidad, la misma tarde en que un cliente podría irse con la misma facilidad. Hacer posible esa tarde nos costó un esfuerzo de ingeniería real. Creemos que es un esfuerzo que había que hacer, y que cualquier proveedor que no esté dispuesto a hacerlo te está diciendo discretamente algo sobre lo seguro que está realmente de lo que vende.