Cette page regroupe différents conseils sur la maintenance long terme de CAMAP.
La plupart de ces travaux à mener sont peu compréhensibles par des non techniciens, mais sont indispensable si l'ont souhaite que CAMAP tienne dans le temps, sans sombrer sous des tonnes de dette technique.
Même si le compilateur Haxe continue à être maintenu, ses applications pour le web ne sont plus maintenues. Les nouvelles évolutions concernent plutôt le champs du jeu vidéo multiplateforme. De même, le runtime Neko n'est plus maintenu.
Il faut donc considérer sérieusement de poursuivre l'effort de migration vers JS/TS même si cela demande un effort considérable.
( Une piste alternative avait été étudiée via une compilation PHP du code Haxe mais n'a pas été poursuivie. )
Passer sur une stack plus connue permet un accès plus facile aux ressources et aux compétences de développement.
Les prochains projets à mener pourraient être :
- Finir de traduire en TS le code Haxe compilé en JS
- Front : Remplacer les interfaces en templates mtt par des interfaces en React
- Back : Ré-écrire les modules en TS petit à petit, et en profiter pour bien les sécuriser avec des suites de tests unitaires ou e2e. Lorsqu'on retire une feature du code Haxe pour la récréer en TS, on peut toujours utiliser un pont pour que le code Haxe appelle des fonctions sur le serveur TS.
- Supprimer au passage les champs de base de données non utilisés, vestiges de fonctionnalités disparues.
Camap-haxe est prévu pour fonctionner sur un serveur avec l'heure française. Les dates stockées dans les tables par le code Haxe sont donc des dates Françaises ( UTC+1 en hiver , UTC+2 en été ).
A l'inverse, camap-ts fonctionne avec des dates UTC ce qui facilite l'internationalisation des apps, mais complique les interactions avec l'app Haxe.
Dans le cadre de la migration vers JS/TS, il faudrait basculer sur des dates UTC dans l'ensemble de la base de données
Actuellement quasiement toutes les entités (tables) de la BDD sont écrites à la fois en TS , à la fois en Haxe, ce qui rend la gestion des évolutions particulièrement fastidieuse et compliquée.
Lorsqu'on porte une fonctionnalité de Haxe vers TS, il devient possible de supprimer l'entité en Haxe.
Typeorm, permet la rédaction de migrations ce qui simplifie grandement la gestion de différentes instances. Chaque mise à jour du schéma de BDD de CAMAP devrait s'accompagner d'une migration.
camap-haxe ne gère pas vraiment UTF-8, c'est pourquoi la base de données contient des chaines UTF-8, mais avec un characterset et une collation MySQL "ISO" (latin1_swedish_ci). Les pages web s'affichent cependant correctement en UTF-8 dans le navigateur.
De l'autre côté, camap-ts fonctionne par défaut en UTF-8.
Malheureusement, il n'est pas possible de passer à un characterset et une collation de type utf8mb4_general_ci car cela ne fonctionne pas avec camap-haxe.
Le monde Javascript / Node Js / Typescript évolue très vite, ce qui nécéssite de mettre à jour les dépendances régulièrement, au moins sur les briques principales ( Nest JS, TypeORM, React, Appolo ...etc) sinon l'application risque de devenir obsolète et difficile à maintenir.
Côté BDD, la version 5.7 de MySQL commence à être ancienne, une évolution vers des versions plus récentes serait bénéfique. ( Si les vieux drivers MySQL de Neko continuent de fonctionner )
Le système actuel est documenté dans theme.md.
Ce système pourrait être améliorer :
- utilisation de variables CSS avec des valeurs précalculées
- Précompiler une version de bootstrap 3.4 avec des variables css à la place des valeurs
- Déclaration des variables css avec valeurs précalculées (plutôt que les fonction sass) dans un fichier styles.css
- Ajout de styles spécifiques dans styles.css également
Les avantages de ce système :
- plus besoin de sass (utilisation des valeurs en dur directement dans un fichier styles.css)
- plus besoin de less (utilisation de variables css pour déclarer les valeurs, dans le même styles.css)
- plus besoin de script ou autre pour recompiler bootstrap lors d'évolutions (une fois compilé avec des variables css il ne bougera plus)
Ainsi il ne resterait que les fichiers :
- boostrap.min.css (qu'on compile une fois pour toute)
- styles.css (dans lequel on définit les variables css que bootstrap pourra utilisée, et les styles additionnels)
- Ajout de l'outil outil post-css un passe de l'outil post-css pour générer styles.min.css (minifié et optimisé pour la cible navigateurs souhaitée, mais en soit styles.css pourraient fonctionner aussi sans retouche)