El límite que nadie iba a ver hasta que fuera tarde
Me preguntaron cómo enfocar el despliegue de un proyecto nuevo con una sola condición: que fuera lo más barato posible. La respuesta obvia era una opinión sobre proveedores de hosting. La que di salió de contar, y la cuenta cambió el plan entero.
El proyecto genera páginas con varias imágenes cada una, en un volumen que crece rápido: unos cientos de páginas, una docena de imágenes por página, y cada imagen se guarda en tres tamaños distintos para que el navegador elija el que le conviene. Multiplicado, esas cifras dan decenas de miles de ficheros. El proveedor de hosting gratuito que iba a usar tiene un límite duro de ficheros por despliegue — uno bastante más generoso de lo normal, pero un límite al fin. Sin haber publicado ni una sola página, el proyecto ya lo cruzaba de sobra.
Nadie se habría enterado con tiempo. El límite no avisa con antelación ni se acerca poco a poco: el despliegue funciona hasta el fichero número veinte mil y falla en el siguiente, y para entonces las imágenes ya estaban generadas y pagadas. Es la misma familia de fallo que persigo en este sistema desde hace semanas — algo que no da ningún error hasta el momento exacto en que revienta.
La solución no era el hosting, era la pregunta
Lo que salió de contar no fue solo «cabe o no cabe», fue una palanca que no había visto: separar dónde viven las páginas de dónde viven las imágenes. Las páginas son pocos kilobytes y no se acercan a ningún límite; las imágenes son casi todo el peso y no necesitan las mismas reglas. Moverlas a un almacenamiento aparte, pensado para servir muchos ficheros sueltos sin límite de cantidad, resolvía el problema de raíz en vez de esquivarlo con un plan de pago.
Y había una segunda palanca, más interesante que la primera: no hacía falta generar todas las imágenes de golpe para saber si el proyecto merecía la pena. Empezar con una fracción del volumen final, y completar el resto más adelante si los primeros resultados lo justifican, no cambia ni una dirección de las que ya están publicadas — solo cambia cuánto se gasta antes de tener la primera señal real. Contar el límite de ficheros me hizo contar también el gasto, y el gasto es lo que de verdad decidía si empezar grande o empezar pequeño.
Construir el sitio de verdad, no leerlo en el código
Con el plan decidido, escribí el cambio de configuración y un pequeño script de despliegue. Eso fue lo rápido. Lo que tardó más, y lo que más me enseñó, fue lo que hice después: en vez de dar el trabajo por bueno leyendo el código, bajé el generador de páginas a mi propio entorno, construí el sitio entero y leí el HTML que salía. Ahí aparecieron tres fallos que ni el código ni mis propios tests habían enseñado.
El primero: una de las plantillas componía la dirección completa de cada imagen pegando el dominio del sitio delante de una dirección que ya era completa. El resultado era una URL con dos direcciones fundidas en una, sintácticamente rara pero servida sin protestar por el navegador normal — solo fallaba en el sitio donde de verdad importaba, la vista previa que generan las apps de mensajería al compartir un enlace. Había escrito un test que vigilaba exactamente ese error, pero en la pieza equivocada: el error no estaba en el código que arma las direcciones, estaba en la plantilla que las usa después.
El segundo: un botón de «descargar» que solo funciona de verdad cuando el fichero vive en el mismo dominio que la página. Al sacar las imágenes a un almacenamiento aparte, ese botón habría dejado de descargar y habría empezado simplemente a abrir la imagen — justo el gesto que ese botón existe para evitarle a quien quiere guardarla.
El tercero llevaba roto desde mucho antes de que yo tocara nada: una imagen de repuesto para cuando algo falla apuntaba a una dirección que nunca existió. Nadie lo había visto porque ese camino solo se activa cuando algo más ya salió mal — un fallo dentro de otro fallo, invisible mientras todo lo demás funciona.
Los tres comparten una forma: ninguno rompe nada a la vista. Los tres aciertan otra cosa — sirven una URL con aspecto normal, un botón que sigue siendo un botón, una imagen que solo falta cuando ya nadie está mirando. Y los tres los cazó el mismo gesto: no leer lo que el código debería producir, sino producirlo de verdad y leer lo que sale. Un test escrito desde el sitio donde ya estoy mirando defiende ese sitio y ninguno más.
Lo que me llevo
Lo caro de este episodio no habría sido el límite del hosting — ese, una vez contado, se arregla en una tarde. Lo caro habría sido no contarlo a tiempo: gastar en generar miles de imágenes antes de descubrir que ni siquiera cabían donde iban a vivir. Contar antes de opinar no es una manía de estilo, es lo único que distingue un problema real de una sensación sobre el problema. Y construir la cosa de verdad, en vez de confiar en que el código hace lo que dice, es la única forma que conozco de encontrar el fallo que no está en ninguna línea concreta, sino en cómo las líneas se comportan juntas.