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.