Contexte
Durant ma carrière j'ai toujours été intéressé par le sujet de l'éco-conception mais dans aucun de mes postes je n'ai eu la possibilité de passer du temps pour approfondir le sujet et le mettre en place.
Il y a 4 mois j'ai commencé mon premier projet en freelance from scratch. Je me suis posé la question de la stack que je pourrais utiliser pour avoir dès le départ un projet le plus sobre possible.
Je développe depuis bientôt 15 ans en javascript puis en typescript, principalement dans l'écosystème React depuis 7 ans. Je ne souhaitais par repartir sur une techno complètement nouvelle donc je voulais trouver quelque chose proche de ce que je connais.
L'appli que je développe est à destination des actionnaires de sociétés d'énergie citoyenne. D'un point de vue technique, pas besoin de SEO, c'est une SPA (Single Page Application) des plus classique.
Les critères que je me suis donné :
- limiter l'utilisation du réseau via un bundle le plus petit possible, peu d'assets de petite taille, des appels API efficients
- limiter l'utilisation des ressources sur le serveur via une librairie d'accès à la base de données la plus efficiente possible
Stack retenue
Après quelques recherches et expérimentation j'ai retenu la stack suivante :
SolidStart
SolidStart est un framework fullstack basé sur le framework SolidJS.
SolidJS possède deux grands avantages pour moi :
- une proximité avec React au niveau de la syntaxe (JSX, composants, ...)
- de très bonnes performances comparées aux autres framework front existants
SolidJS est plus performant que React car par défaut les composants ne se rendent qu'une seule fois. C'est à nous développeur ensuite d'utiliser les signals pour ajouter de la réactivité là où c'est nécessaire.
En plus de cela SolidStart apporte un framework fullstack très productif notamment grâce aux server functions qui permettent un typage fort de bout en bout et une écriture simplifiée des API. La brique de sérialisation “Seroval” est très performante et pour la mise à jour de données les single flight mutation permettent de réduire les allers retours réseau.
Si vous voulez débuter avec SolidStart, je vous conseille de lire cet article sur les bonnes pratiques qui résume bien les points d'attention notamment pour un ex développeur React.
Drizzle
Pour l'accès aux bases de données j'avais pour habitude d'utiliser un ORM assez classique. En typescript j'ai notamment utilisé MikroORM qui reprend pas mal de concepts d'Hibernate en Java que j'avais utilisé précédemment.
Pour ce projet j'ai décidé de changer pour utiliser Drizzle qui est une surcouche plus fine au dessus de la base de données. L'idée est de s'appuyer plus sur le sql pour diminuer l'overhead de la couche d'accès aux données.
Après plusieurs mois d'utilisation j'avoue être très content de l'outil. Couplé avec SolidStart on arrive à avoir un typage fort de bout en bout qui est très efficace et très pratique.
Tailwind et DaisyUI
Pour la partie design je préfère en règle générale faire directement du CSS lorsque je travaille avec un UI/UX designer pour pouvoir faire du pixel-perfect. Sur ce projet je n'avais pas ce luxe et j'ai donc cherché une librairie de composants plus ou moins clé en main.
Malgré cela je ne voulais pas quelque chose de trop lourd et au final j'ai fait le choix de DaisyUI qui est une surcouche à Tailwind qui est plutôt légère.
Résultats
Pour vous donner une idée de la taille de l'application que j'ai développé, elle comporte environ 75 routes et la base de données contient 35 tables. Je dirais que c'est une application de taille moyenne.
Voici quelques métriques en terme de taille de bundle :
- Le bundle total de l'app gzippé fait 385 ko dont 153 ko pour la librairie apex-charts qui est utilisée uniquement sur quelques pages qui affichent des graphes
- Pour la plupart des pages de l'app la totalité des données transférées sur le réseau est entre 130 et 200 ko
- le css de l'application fait 20 ko compressé
Si j'active la limitation réseau sur le navigateur pour passer en “Regular 3G”, j'ai un temps de chargement des pages autour de 2,5s et une navigation dans l'application qui est fluide.
Côté serveur je n'ai installé aucun outil de monitoring donc c'est dur de quantifier la charge mais mon appli tourne sans problème sur le plus petit VPS Lite d'Infomaniak.
Conclusion
Même si l'eco-conception ne s'arrête pas à la taille du bundle client et aux ressources utilisées côté serveur, limiter ces valeurs est une condition nécessaire pour ensuite pouvoir développer une application qui tournera sur n'importe quel terminal client.
Au niveau de mes choix, j'aurais pu aussi changer de langage et tester par exemple un framework comme Dioxus en Rust mais cela aurait nécessité un apprentissage encore plus en profondeur au détriment de la productivité sans que je sois vraiment capable de mon côté de mesurer les gains obtenus.
Avec le recul de mes 4 premiers mois de développement, les choix que j'ai effectué me paraissent bon pour avoir une application la plus économe en ressources possibles dans l'écosystème typescript. Je trouve que c'est un bon compromis entre sobriété et productivité.
Une fois ces bases mises en place il faut également réfléchir à la façon dont on conçoit l'application pour continuer à avoir une utilisation sobre des ressources par exemple en paginant systématiquement les listes.