Una biblioteca diez veces mayor y renders que ordenan

Cada plantilla animada es un pequeño componente de React con su propia descripción de los campos que acepta. Añadir 664 le dio a TypeScript cientos de formas nuevas que comprobar, y al build cientos de archivos nuevos que compilar.

Es un buen problema: significa que el producto se ha enriquecido. Pero las herramientas traen límites por defecto, y Node da a cada proceso una cantidad fija de memoria de trabajo salvo que se le diga otra cosa. Nuestra comprobación de tipos y nuestro build de producción simplemente habían superado esa cantidad. Nuestras versiones solo salen cuando han pasado todas las comprobaciones, así que la nueva biblioteca esperó en esa puerta hasta que los controles pudieran terminar.

Lo fácil habría sido subir la memoria de Node en todas partes. Decidimos no hacerlo, porque el servicio web que responde a tus peticiones tiene su propio límite, y más margen ahí solo escondería algún día una fuga lenta.

Así que el espacio extra va exactamente a tres sitios:

• la comprobación de tipos lleva su propio margen, más amplio;
• los controles automáticos que corren antes de cada versión lo fijan para sus pasos;
• la construcción de la imagen lo sube solo para el comando de build, así que el servicio que corre después no cambia.

Con eso, los controles pasaron y el banco de animaciones salió el mismo día. También adoptamos una costumbre: cuando una biblioteca crece en cientos de archivos, medir la memoria del build antes de la versión, no después.

El segundo trabajo tenía que ver con el espacio en disco. Antes de dibujar un vídeo, Remotion empaqueta su código en un bundle, una carpeta que lee el renderizador. Esa carpeta ocupa unos 0,9 GB, va a parar al directorio temporal del sistema y nada la borra cuando el trabajo termina.

Donde se hacen nuestros vídeos, esto no importa nunca. Cada render corre en su propio trabajo efímero, y cuando termina, su disco desaparece con él. En las máquinas duraderas, en cambio, cada bundle se queda. Comprobar 664 plantillas en tres formatos supuso muchos renders en un día en nuestra máquina de desarrollo, y las carpetas se sumaron rápido: 657, unos 42 GB.

Queríamos un render que no dejara nada atrás, corra donde corra. Así que escribimos una pequeña función, cleanupBundleOnExit, y envolvimos con ella cada llamada al bundler, en el código de render y en cada script que crea un bundle.

• Se ejecuta al terminar con normalidad, con una salida explícita y con Ctrl-C o una señal de parada.
• Solo borra una carpeta con nombre de bundle de Remotion, situada directamente en el directorio temporal, así que nunca puede tocar otra cosa.
• Un test específico comprueba que todos los sitios que crean un bundle la usan.

A propósito no escribimos un barrendero que vacíe todo el directorio temporal cada cierto tiempo. Esa carpeta la comparten todos los demás programas de la máquina, y una herramienta que borra por patrón en un lugar compartido es justo la que un día borra lo que no debe. Cada proceso ordena ahora solo lo que él mismo creó, nada más.

No verás nada de esto directamente, y de eso se trata. Las tarjetas animadas llegaron al producto el día en que estaban listas, y las máquinas que comprueban cada plantilla y cada vídeo conservan el espacio que necesitan para volver a hacerlo mañana.

También significa que podemos seguir haciendo crecer la biblioteca. Cada nuevo lote de plantillas llega ahora con dos preguntas ya resueltas: si el build tiene memoria para él y si cada render limpia lo suyo. Las dos tienen su test.

Ninguno de los dos cambios corregía un fallo de nuestra lógica. Ambos venían de la escala: una biblioteca que crece en cientos de componentes cambia la memoria de un build y el disco que deja un render. Una revisión de código no muestra ninguna de las dos cosas; una medición, sí.

Así que ahora tratamos un gran salto de contenido como una nueva función: medimos lo que le cuesta a la maquinaria, le damos espacio justo donde lo necesita y comprobamos que todo lo que escribe archivos temporales también los borra.