raas, rounding as a service: la api de broma que redondea números

raas significa rounding as a service. es una api que hace una sola cosa, redondear números, y que se vende como si fuera infraestructura crítica. tiene tres planes de pago y un nombre registrado para cada método, y cada respuesta te dice cuánta precisión has perdido.

el 2 de marzo la publiqué en linkedin, escrita como un lanzamiento b2b de verdad, y tuvo 419 impresiones y 4 reacciones. después la publiqué en reddit, donde pasó de 440.000 visualizaciones y fue el post más visto de ese día en la portada de r/programmerhumor.

la broma tiene que parecer un producto

la regla era que la página, leída en diagonal, pasara por un saas cualquiera. el titular dice "enterprise-grade decimal management". debajo están las tres insignias de siempre: "99.999% uptime sla", "soc 2 type ii" y < 0.3ms latency. ninguna de las tres es cierta, y la tercera la desmiente la propia api.

los precios siguen el mismo patrón. el plan gratuito incluye "community support (reddit)". el pro cuesta 49 dólares al mes y ofrece "priority latency (+40ms faster)". el enterprise cuesta 99 e incluye una "rounding insurance policy" y despliegue on-premise. bajo los tres planes, en letra pequeña: "all plans include 256-bit aes encryption for your decimals. because security." el botón "schedule a demo" lleva a un rick roll.

los tres métodos son tres funciones de la librería estándar de javascript con un nombre registrado:

la gracia está en la distancia entre la frase y el código. la web describe smart rounding como "ai-adjacent proximity snapping" que evalúa algorítmicamente el delta de tu decimal respecto a los enteros vecinos. es Math.round.

la api funciona de verdad

una landing de broma la puede hacer cualquiera. lo que hace que aguante es que, cuando alguien copia el ejemplo de la portada y lo prueba, le responde una api de verdad, con el mismo tono. el núcleo son siete líneas:

if (methodParam === "smart") {
  result = Math.round(num);
} else if (methodParam === "elevate") {
  result = Math.ceil(num);
} else {
  result = Math.floor(num);
}

el resto es envoltorio. la primera versión ya redondeaba exactamente igual. toda la broma entró después en un solo commit, que hizo pasar la ruta de 87 a 116 líneas, y ninguna de las líneas nuevas redondea nada. la respuesta que sale en el readme es esta:

{
  "status": "success",
  "data": { "original_value": 4.82, "rounded_value": 5, "precision_loss": 0.18 },
  "metadata": {
    "algorithm_used": "Smart Rounding™",
    "computation_time_ms": 112.45,
    "is_integer": true
  }
}

precision_loss es la diferencia entre el número que envías y el que te devuelve, para que sepas cuánta información has destruido. is_integer es true porque el resultado sale de Math.floor, Math.ceil o Math.round. solo es false en un caso. si envías Infinity, la api responde "status": "success" con todos los valores en null, porque json no tiene manera de escribir infinito.

computation_time_ms es el campo que más me gusta. la portada promete menos de 0,3 ms, y la api le suma entre 40 y 120 ms inventados:

const fakeLatency = Math.random() * 80 + 40;

los errores también forman parte del producto. cada uno usa el código http que toca, con un mensaje corporativo:

• apple o banana devuelven un 418 i'm a teapot: "cannot apply mathematical truncation to fruit." el 418 viene del rfc 2324, la broma del 1 de abril de 1998 sobre cafeteras. una pera, en cambio, no cuenta como fruta y devuelve un 422.
• cualquier otra cosa que no sea un número devuelve un 422 unprocessable entity, que te pide "a compliant 'number' query parameter".
• un método que no existe devuelve un 400: "is not a recognized corporate rounding strategy".
• un método de un plan superior al tuyo devuelve un 402 payment required: "the 'smart' algorithm is locked behind a higher paywall." el estándar http lleva décadas con el 402 reservado para uso futuro. aquí sirve para lo que dice su nombre.

el repositorio también es parte de la broma

el readme tiene las insignias de un proyecto serio: build passing, 99.999% de uptime, una serie a de 14 millones de dólares y 8.432 dependencias. solo se aceptan pull requests de "developers with at least 15 years of experience in decimal mitigation". al final hay una nota para el equipo: "please stop committing the .env file. dave, this is your last warning."

el .env, evidentemente, está en el repositorio. el commit que lo añade también quita del .gitignore la línea .env* que create-next-app pone por defecto. para poder subir el fichero, primero tuve que deshacer la protección contra subirlo. dentro hay:

• una REDIS_CACHE_URL con el comentario "used for caching the number 4".
• ENABLE_QUANTUM_FLOORING=false, porque "it was occasionally rounding 2 down to 1".
• una base de datos que se llama fractional_reserve_db, donde se guardan "the decimals we shave off from the free tier users".

la misma broma en reddit y en linkedin

el primer post en linkedin lo escribí con el tono de los lanzamientos de linkedin: "¿estamos delegando tareas hipercomplejas a la ia, pero seguimos gestionando nuestros propios decimales en local? es una locura." 419 impresiones, 4 reacciones. en reddit, la misma sátira pasó de 440.000 visualizaciones.

no tengo datos para saber por qué. lo que sí veo es una diferencia de contexto. en linkedin, una parodia de un post de lanzamiento b2b se lee como un post de lanzamiento b2b más, porque se parece demasiado al resto del feed. en r/programmerhumor, antes de leer nada ya sabes que es una broma, y quien la lee sabe qué hace Math.round.

el otro dato es el del segundo post. el 9 de marzo volví a linkedin a contar lo que había pasado en reddit, y tuvo 783 impresiones, casi el doble que el primero. en linkedin funcionó mejor explicar el éxito de la broma que la broma en sí.

en github, el repositorio tiene 21 estrellas y ningún fork. la api, mientras tanto, sigue respondiendo que no puede truncar fruta.