Une bibliothèque décuplée, des rendus qui rangent tout

Chaque modèle animé est un petit composant React, avec sa propre description des champs qu'il accepte. En ajouter 664, c'est donner à TypeScript des centaines de nouvelles formes à vérifier, et au build des centaines de nouveaux fichiers à compiler.

C'est un bon problème : le produit s'est enrichi. Mais les outils ont des limites par défaut, et Node accorde à chaque processus une quantité fixe de mémoire de travail, sauf indication contraire. Notre vérification de types et notre build de production avaient tout simplement dépassé cette quantité. Nos versions ne partent qu'une fois toutes les vérifications passées : la nouvelle bibliothèque a donc attendu à cette porte que les contrôles puissent aller au bout.

Le plus simple aurait été d'augmenter la mémoire de Node partout. Nous ne l'avons pas fait : le service web qui répond à vos requêtes a sa propre limite, et une marge plus grande à cet endroit ne ferait qu'un jour masquer une fuite lente.

La place supplémentaire va donc à trois endroits précis :

• la vérification de types porte sa propre marge, plus large ;
• les contrôles automatiques lancés avant chaque version la fixent pour leurs étapes ;
• la construction de l'image l'augmente pour la seule commande de build, si bien que le service lancé ensuite reste inchangé.

Ainsi, les contrôles sont passés et la banque d'animations est sortie le jour même. Nous avons aussi pris une habitude : quand une bibliothèque grandit de centaines de fichiers, mesurer la mémoire du build avant la version, pas après.

Le second chantier concernait l'espace disque. Avant de dessiner un film, Remotion emballe le code du film dans un bundle, un dossier unique que le moteur lit. Ce dossier pèse environ 0,9 Go, il atterrit dans le répertoire temporaire du système, et rien ne le supprime une fois le travail fini.

Là où nos films sont fabriqués, cela ne compte jamais. Chaque rendu tourne dans sa propre tâche éphémère, et quand la tâche se termine, son disque disparaît avec elle. Sur les machines durables, en revanche, chaque bundle reste. Vérifier 664 modèles dans trois formats représentait beaucoup de rendus en une journée sur notre machine de développement, et les dossiers se sont vite accumulés : 657, soit environ 42 Go.

Nous voulions un rendu qui ne laisse rien derrière lui, où qu'il tourne. Nous avons donc écrit un petit utilitaire, cleanupBundleOnExit, et enveloppé avec lui chaque appel au bundler, dans le code de rendu comme dans chaque script qui crée un bundle.

• Il s'exécute à une fin normale, à une sortie explicite, et sur Ctrl-C ou un signal d'arrêt.
• Il ne supprime qu'un dossier nommé comme un bundle Remotion, posé directement dans le répertoire temporaire : il ne peut rien toucher d'autre.
• Un test dédié vérifie que chaque endroit qui crée un bundle l'utilise.

Nous avons volontairement renoncé à un balayeur qui viderait tout le répertoire temporaire à heure fixe. Ce dossier est partagé avec tous les autres programmes de la machine, et un outil qui supprime par motif dans un lieu partagé est exactement celui qui, un jour, efface la mauvaise chose. Chaque processus ne range plus que ce qu'il a créé, rien de plus.

Vous n'en verrez rien directement, et c'est bien le but. Les cartes animées sont arrivées dans le produit le jour où elles étaient prêtes, et les machines qui vérifient chaque modèle et chaque film gardent la place nécessaire pour recommencer demain.

Cela signifie aussi que nous pouvons continuer à agrandir la bibliothèque. Chaque nouveau lot de modèles arrive désormais avec deux questions déjà réglées : le build a-t-il la mémoire nécessaire, et chaque rendu range-t-il derrière lui. Chacune a son test.

Aucun de ces changements ne corrigeait une erreur de logique. Tous deux venaient de l'échelle : une bibliothèque qui grandit de centaines de composants change la mémoire d'un build et le disque laissé par un rendu. Une revue de code ne montre ni l'un ni l'autre ; une mesure, si.

Nous traitons donc désormais un grand saut de contenu comme une nouvelle fonctionnalité : nous mesurons ce qu'il coûte à la machinerie, lui donnons de la place exactement où il en a besoin, et vérifions que tout ce qui écrit des fichiers temporaires les supprime aussi.