Pour ce premier article de ce blog, je vais parler d'un projet open source dont je suis assez fier, Indigo. Indigo c'est quoi ? Il s'agit d'un Framework de développement pour les sites web que j'ai conçu à la base pour répondre aux besoins spécifiques que j'avais pour la création du site Tidle.fr. Pourquoi je vous en parle ici et maintenant ? Tout simplement car le développement de sa V2 est sur le point de commencer, avec comme objectif une sortie vers décembre de cette année.

Histoire de sa création

Avant d'utiliser Indigo, je codais mes sites web comme d'une façon archaïque : en PHP directement depuis le client FTP du serveur. Cella ne me posait pas de problèmes, jusqu'à ce que je découvre le gestionnaire de source git,  que j'ai voulu dès lors utiliser pour le développement de mes sites. Au départ, voulant toujours coder en PHP, je continuais à travaillais directement sur le client FTP, et à télécharger de temps en temps sur GitHub le code, mais cette façon de fonctionner n'est pas du tout optimale. Alors pourquoi je ne suis pas passé directement à un développement en local ? Pour la simple raison que j'utilisais PHP, avec des includes et des adresses complètes pour les ressources (ex: assets.tidle.fr). D'abord, PHP constituait en soi un problème à l'exécution de mes sites en local, passer à WampServer sur mon ordinateur sous Windows cassait certaines des configurations spécifiques à mon environnement serveur PHP de production, avec des modules PHP spécifiques Linux, s'en parlais de mon ancien système de gestion de fichiers qui ne savait plus où donner de la tête parfois en passant d'une syntaxe Windows à Linux, et les adresses des ressources cassées, car ne pointant pas sur des ressources sur le même domaine, par exemple pas /assets/logo.png mais un domaine dédié comme ceci : assets.tidle.fr/logo.png.

Alors comment ai-je régler ces problèmes ? Je n'avais pas à l'idée dans un premier temps lorsque j'ai commencé, de faire un Framework qui en soit serait réutilisable pour tous mes autres projets, pour preuve que les premières versions du futur Indigo se situaient sur le dépôt git du site de Tidle.fr, et non sur un dépôt dédié. Le système fonctionne depuis son début sous Node.js, c'était le choix le plus pratique, le JavaScript étant assez simple à prendre en main. La première version était très simpliste, il s'agissait d'un simple script qui récupérait dans un JSON les fichiers déclarés, et regardais à l'intérieur des pages HTML les différents liens pour les convertir, soit en adresse locale pour le développement, soit en les remplaçants par les noms de domaines situés dans une configuration pour les mettre en ligne sur le serveur du site, avec une petite bidouille pour pouvoir servir un serveur PHP directement depuis Node.js. Je ne vais pas tous détailler ici, car je ne me souviens moi même plus de tous, mais pour plusieurs limites qui sont apparues à l'utilisation, je suis parti pour la première grosse réécriture du programme, dans le but cette fois d'en créer un programme indépendant, disponible en open source, la V1 d'Indigo, qui est à l'heure où j'écris ces lignes la première et dernière version stable (même si pas trop) disponible.

Les avantages et spécificités

Pourquoi vous allez me dire je ne suis pas partis sur un Framework déjà existant comme Angular, Vue ou React ? Parce que je les trouve trop lourds, contraignants, et que je ne sais pas, au vu de toutes les fonctionnalités qu'ils offrent, s'ils répondent à mes besoins primaires. Pour me faciliter la vie, je suis parti avec Indigo sur un système de fichier que j'utilisais déjà et que je vais détailler.

Tout d'abord, ce que je voulais absolument était un système qui permette de ne pas faire de calcul ou de rendu au serveur qui dessert le site, j'avais pour objectif avec cette règle de rendre le site sur le serveur totalement statique, et donc de le rendre facilement hautement disponible en cluster. Avec Indigo, on peut créer des templates de page ou des composants (appelés layouts) qui vont nous permettre de réutiliser des éléments sur plusieurs pages, mais ceux-ci sont compilés pour constituer des pages statiques au format HTML.

Tout le routage d'Indigo s'effectue en PHP pour desservir les pages statiques, les pages sont triées dans différents dossiers que l'on appelle ici routes, chaque route peut constituer une version différente des pages. Par exemple, on peut créer une route accessible par toutes les personnes connectées ou non, une route pour les personnes non connectées, et une route pour les personnes connectées. Ceci permet de bien différencier nos pages. Il suffit alors dans le fichier du routeur de créer des règles pour dire à quel moment on doit rediriger vers une route, et ensuite c'est le contrôleur de la route qui va gérer la partie finale, à savoir rediriger vers la page correspondante à l'URL de requête.

Pour pouvoir rendre son contenu dynamique, tout se passe en javascript côté client, ce qui permet d'enlever la génération des pages au serveur. Une passerelle API est par défaut créée sur domaine.tld/api, qui permet de toujours récupérer les cookies du site protégés en HttpOnly. L'api bénéficie de sécurités, comme la présence par défaut d'un token CRSF pour protéger son site, ou encore du contrôle de l'origine et du SSL. Toutes ses fonctions sont disponibles en environnement de production, mais également en environnement de développement, pour ce faire bon nombre de celles-ci sont compilées différemment entre les deux, et une image Docker spéciale a été crée pour pouvoir en plus bénéficier de la prise en charge des modules PHP pour communiquer avec les bases de données PostgreSQL, MariaDB, MongoDB, Redis, ou encore Memcached, toutes prises en charge pour le développement de vos sites avec Indigo. Il s'agissait là aussi d'un problème rencontré pour passer au développement local, résolu grâce à l'arrivée de Docker sur Windows (et plus seulement Windows pro), dont Indigo gère entièrement la création et la gestion.

Indigo inclut également un petit algorithme qui permet de regrouper en un seul fichier les différents fichiers JavaScript, en les assemblant de manière optimale, en prenant en compte leur présence sur les différentes pages. C'est une fonction qui fu difficile à mettre en place, qui présente beaucoup de bugs, et qui en plus ne semble pas accélérer le chargement des pages, sa pérennité sur la nouvelle version et donc des plus incertains.

Le futur d'Indigo

Le futur d'Indigo est plutôt prometteur, il n'y a qu'a voir la RoadMap, elle est assez bien fournie et je vais essayer d'approfondir quelques points ici, qui me serviront aussi de pense-bête pour plus tard.

Code source totalement réécrit

Le code source d'Indigo va être totalement réécrit, et on va changer pour passer du javascript au typescript ! En effet, le cœur d'Indigo reste un enchevêtrement d'idées, sans aucun but, ni même de vision sur le futur, j'ajoutais alors tout ce à quoi je pensais. Une réécriture complète du code, en anticipant mieux les nouveaux ajouts de fonctionnalités, ne sera que bénéfique, et permettra en même temps de régler les quelques bugs de la V1 qui me sont apparus en utilisation. Le typescript sera le must have si je peux dire, qui permettras normalement de garder un code propre et maintenable en forçant un minimum l'utilisation de bonnes pratiques comme les classes et le typage.

Test unitaire

Pour éviter les bugs qui sont arrivés sur la V1 d'Indigo, les tests unitaires vont faire leur apparition sur le code source d'Indigo, pour permettre de vérifier et débugger plus facilement le code. Cella va également permettre de vérifier que dans certaines configurations très spécifiques aucun bug n'apparaît, et d'ajouter aux tests ces mêmes configurations qui seront reportées en issues GitHub. Ces tests seront effectués avec le Framework de test Mocha, complété par des actions GitHub pour automatiser le processus.

Changements du système API

Un ajout de la prise en charge du temps réel pour l'API devrait également faire son apparition, pour permettre aux sites d'avoir une passerelle API réagissant aux requêtes temps réel. Cette implémentation du temps réel reste encore à réfléchir et à définir, il s'agira surement d'un des derniers ajouts. Autre ajout pour l'API, un système de cache automatique, qui devrait fonctionner sous Memcached pour permettre de ne pas appeler vos bases de données pour les mêmes données, en facilitant la gestion du cache avec des règles simples pour les développeurs.

Déploiement enrichi

Le déploiement sera enrichi. Normalement, ce sera fini l'utilisation obligatoire du moteur PHP couplé à apache, vous pourrez normalement choisir à l'avenir dans la configuration la plateforme finale, entre Nginx/Apache et PHP/Node.js. L'intégration reste encore là à réfléchir, car tout le routage ne pourra plus se faire en PHP, mais je tiens à ce que plusieurs possibilités de déploiement soient offertes aux utilisateurs, dans ce même cadre de déploiement enrichi, des actions à utiliser sur GitHub devraient faire leur apparition pour faire du déploiement continu avec Indigo, et de rendre la mise à jour de votre site plus rapide.

Mise à jour du site en production

La mise à jour de votre site en production est l'une des fonctionnalités que j'envisageais pour la V1, mais que je n'avais pas effectuées, sachant déjà avant même la fin que je reprendrais le code de zéro pour mieux intégrer cette partie. Cella permettra, lorsque vous avez publié votre site avec les fichiers de production d'Indigo, de générer avec le Framework un build spécialement conçu pour mettre à jour votre site, en donnant par exemple, une date de mise à jour au site. Vous n'aurez alors plus qu'à télécharger ce nouveau build dans un dossier spécifique sur votre serveur, et la mise à jour s'effectuera automatiquement, sans interruption de service pour vos utilisateurs.

Gestion de Docker améliorée

La gestion de docker va être fortement améliorée (en même temps, actuellement ce n'est pas difficile). Pour faire simple, à l'heure actuelle, les conteneurs Docker des bases de données et de l'environnement serveur sont gérés au travers de l'invite de commande, ce qui peut générer des crashs, et je ne parle même pas de la comptabilité avec les petites différences qui peuvent exister entre les systèmes d'exploitation Windows, Mac OS et Linux. La prochaine version d'Indigo communiquera normalement directement avec le Docker daemon, au travers de l'API REST fournie par celui-ci, la gestion de Docker en sera que d'autant plus facilitée et stable.

Prise en charge des éléments SEO

Oui, le SEO est un problème sur la version actuelle d'Indigo, c'est pour cella que la prochaine version bénéficiera d'un support complet : sitemap.xml, robots.txt, descriptions pour les pages, mots clefs, balises open graph, ainsi que les balises des réseaux sociaux Facebook et Twitter (proposez si vous avez d'autres besoins).

Ajout d'une vraie bibliothèque JavaScript

C'est bien beau de créer un site entièrement en JavaScript, mais encore faudrait-il que l'on puisse se faciliter la vie avec celui-ci. Tout d'abord, un support de Typescript devrait être présent pour la création de vos sites (encore à méditer), mais en tout cas, une bibliothèque bien plus fournie verra le jour pour la création de composants, mise à jour d'élément, modification des entêtes, titre, etc.

Documentation

C'est là peut-être le meilleur, sur la V1, la doc a été, disons… délaissée. Pour la V2, l'obligation sera faite pour les développeurs, ou pour une personne dédiée, de documenter correctement tous les ajouts, afin de pouvoir écrire par la suite une documentation sur le wiki. Le but est de pouvoir bénéficier d'une vraie documentation, car en l'état actuel des choses, à part moi même, je ne vois personne capable de développer sans soucis avec Indigo (et même moi j'ai du mal).

Plusieurs personnes pour le projet ?

Si vous êtes arrivé jusqu'ici, vous êtes sûrement beaucoup intéressé par Indigo (et je ne sais pas pourquoi vu mon article). Mais si vous êtes intéressé, et même si vous ne développez pas (n'ayez pas peur), je serais ravi de parler avec vous d'Indigo. Et si vous êtes développeur, je serais encore plus content de pouvoir me faire aider dans le développement, dans une ambiance bonne enfant et conviviale, tout en apprenant des uns et des autres. Vous êtes convaincus par la future version du Framework ? Contactez-moi !

Logo/mascotte ?

Ce n'est pas vraiment que mes talents artistiques sont limités (si), mais une aide pour la création d'un logo ou d'une mascotte pour le projet ne me serais pas de trop. Toutes les propositions sont les bienvenues, il n'y a pas vraiment d'attentes. Encore une fois, contactez-moi !

Merci d'avoir lu ce premier article de mon blog, si vous l'aimez, ou si vous connaissez des personnes susceptibles d'êtres intéressés, partagez !

Dépôt GitHub d'Indigo => github.com/Tidle-Groupe/Indigo