De vez en cuando entro en npm a mirar cómo le va a datetoken. Unas mil doscientas descargas a la semana, cero proyectos que dependan de ella. Mi teoría es que son los pipelines de CI de mi antigua empresa, ejecutándose con la puntualidad que nunca tuvieron nuestros informes. Si es así, es el usuario más fiel que he tenido nunca.

El problema, que era de verdad

Datetoken nació en wocu-monitoring.com, donde casi todo lo que pintábamos era una ventana de tiempo relativa: las últimas 24 horas, la última semana. Si el frontend resolvía “las últimas 24 horas” a dos timestamps y los metía en la URL, cada petición era única en el universo y la caché del recurso no servía para nada, porque el “ahora” cambiaba en cada segundo que pasaba.

La solución era no resolver. El frontend manda el token tal cual, now-24h, la URL es siempre la misma, la caché por fin trabaja, y es el servidor quien resuelve el “ahora” cuando le llega la petición. Después resultó útil también en el backend: los informes periódicos necesitaban rangos relativos por definición, porque un informe semanal con fechas absolutas solo es correcto una vez.

La metástasis

La escribimos primero en Python y luego en JavaScript. Hasta ahí, lo normal: dos implementaciones porque había dos runtimes que la usaban. Luego me fui de wocu y la cosa siguió por su cuenta: Rust, Go, Deno, que había olvidado por completo hasta hoy, y hasta Nim, cortesía de Fer, que creo que no ha ejecutado nadie jamás, incluidos nosotros. Eran los tiempos en que cualquier cosa se convertía en un SaaS, así que bromeábamos con montar datetoken as a service: un endpoint que te devuelve dos fechas. Por los LOLes. Menos mal que nos dio la risa antes que la ronda de financiación.

Hay que decir que el problema no pedía tanto. Un token de fecha se resuelve con dos expresiones regulares y un poco de vergüenza. Pero yo estaba leyendo Writing an Interpreter in Go y Writing a Compiler in Go, así que datetoken tiene lexer, parser recursivo descendente y AST. Cuando tienes un martillo así de bonito, todos los problemas son lenguajes de programación.

Mantenimiento, que es como se dice adiós en open source

Hoy las librerías están en modo mantenimiento porque no queda nada que hacerles. Un token de fecha no acumula requisitos. Y la parte de escribirlas desde cero, que entonces era el proyecto, hoy se la pides a cualquier modelo y te la da en dos minutos, probablemente con mejores tests.

Así que esto era un pequeño homenaje a esa categoría de software: la utilidad de doscientas líneas que resolvía un problema real de una empresa real, que casi nadie más usó y que no lo necesitaba. Se aprendía una barbaridad escribiéndolas. Las mil descargas semanales, sean de quien sean, se agradecen igual.