Comics : notes de développement
Quelques notes sur le développement de mon outil de gestion de bds numériques alors que la version 2 approche...
Une version 2 simplifiée
La première version utilisait des échanges de données entre le navigateur et le serveur un peu complexes. Je transmettais des « delta » de donnée, quand un bouquin était ajouté / supprimé / modifié, ou bien quand un dossier était ajouté / déplacé / supprimé, etc.
Efficace quand à la réduction de la taille des requêtes http mais exigeant quant à la complexité du code, à la fois côté navigateur ET côté serveur.
Avec la deuxième version, j'ai adopté une architecture différente, héritée du développement d'une autre application, Feeds : toute la logique métier est portée côté navigateur. Le code serveur nodejs est donc là presque uniquement pour fournir (get) ou enregistrer (put) la donnée, à une exception prêt.
Les échanges avec le serveur sont un plus lourds (quelques dizaines de Ko au lieu de quelques Ko) mais cela reste léger. Surtout, cela à l'énorme avantage de simplifier le code, donc de faciliter sa maintenance et son évolution.
Le combat des zippers
Les bédés numériques sont au format cbz, en tout cas celles que l'application gère. J'utilise JSZip depuis plus d'une décennie mais, mécontent des performances, j'ai cherché des alternatives.
J'ai envisagé un moment d'utiliser zip.js mais les gains ne m'ont pas semblé notables. Surtout, il n'est pas utilisable côté serveur sous nodejs.
j'ai fini par essayé fflate et les résultats ont été suffisamment encourageant pour lancer quelques tests de comparaison avec JSZip...
Lecture de fichier
La lecture consiste à lire l'ensemble des fichiers images d'une archives cbz et de construire des blobs pour chacune d'elles.
| Fichiers | JSZip | Fflate |
|---|---|---|
| 20 Mo (39 fichiers) | 385 ms | 398 ms |
| 32 Mo (18 fichiers) | 649 ms | 604 ms |
| 60 Mo (35 fichiers) | 969 ms | 945 ms |
Les temps de lecture sont assez comparables entre les deux outils, même si Fflate a souvent été légèrement plus performant.
Extraction de la couverture
Quand l'application enregistre une nouvelle bédé, elle doit en extraire la couverture (la première image).
| Fichiers | JSZip | Fflate |
|---|---|---|
| 20 Mo (39 fichiers) | 86 ms | 89 ms |
| 32 Mo (18 fichiers) | 185 ms | 82 ms |
| 60 Mo (35 fichiers) | 204 ms | 63 ms |
Là par contre Flate a semblé plus performant que JSZip, surtout avec les plus gros fichiers. Il semble être capable de lire l'index des fichiers contenu dans le zip bien plus vite.
Conclusion
Après des années d'usage, j'ai donc abandonné JSZip au profit de Fflate :
- Les performances sont meilleures.
- Flate est au format ESM donc bien plus facilement intégrable à l'application.
- Fflate est plus léger.
- Avec Deno, il est possible de n'utiliser que la version web de la librairie.
Donc, Salut JSZip, et encore merci pour le poisson !
Se débarrasser de JSDom
J'utilise JSDom sur ce site depuis quelque temps pour générer des pages web côté serveur. Je l'utilisais dans Comics pour générer un arbre opml représentant l'arborescence des dossiers.
Un peu comme utiliser un bazooka pour tuer une mouche !
J'ai donc décidé de m'en passer simplement en manipulant des tableaux d'objets puis en sérialisant le tout sous forme de string xml . À la « old school » quoi !
Une cinquantaine de lignes de code pour se débarrasser de 2.95 Mo de dépendances (dont je n'utilisais qu'une petite partie), on peut dire que ce n'est pas du temps perdu 😄.
Tree Shaking sans bundling ?
Le « Tree Shaking » (ou secouer le cocotier) est une technique qui consiste à se débarrasser du code inutilisé ; cela permet d'alléger le code en production.
Il a du sens lorsque l'on génère des « bundles », la fusion du code d'une application en un seul ou quelques fichiers pour diminuer le nombre de requêtes http lors de son fonctionnement.
Comics n'utilise pas de bundler comme Webpack, le code reste à l'état de module lors de son exécution. J'aimerai cependant avoir un outil qui me permette de construire une version de production ou seuls les modules utiles d'un projet sont distribués.
Je prend l'exemple du projet rnb-ui : c'est une librairie graphique dont j'utilise plusieurs composants web (onglets, barres d'outils, dialogues, etc.). J'aimerai pouvoir distribuer Comics en n'embarquant que les composants utilisés, pas tous le projet. En gros un algo qui scanne l'arbre des dépendances du projet qui, au lieu d 'éditer/concaténer le tout dans un seul fichier, se contenterait de copier les fichiers.