Par Marc Doucet : Analyste en Automatisation Logiciel
15 février 2024
Lors d’un précédent mandat, on m’a demandé d’entretenir une solution de génération de données massive, entièrement programmée dans Postman. Généralement utilisé pour tester des appels d’API, Postman peut aussi être utilisé pour écrire des scripts de prérequête et des tests en JavaScript. Dans le cas qui nous occupe, la solution Postman contenait une programmation complexe : un millier de lignes de code répartis dans plusieurs modules interdépendants.
Description de la solution de départ
Afin de faciliter la compréhension de la solution, limitons-en la description à ceci : un outil utilisé dans les environnements de développement pour générer des clients et des soumissions.
Cette génération nécessite des fichiers CSV, un pour la génération de clients et un pour la génération de soumissions. Ils contiennent les valeurs nécessaires à la saisie : nom, prénom, adresse, etc. Chaque ligne d’un fichier de données représente une itération de saisie (un client ou une soumission). Certaines de ces valeurs peuvent être générées aléatoirement. L’utilisation de fichier CSV pour paramétrer les tests est une fonctionnalité de base dans le module Collection Runner de Postman.
La complexité de la programmation de cette solution se trouve dans l’orchestration des appels d’API en fonction du contenu des fichiers de données. Postman ne dispose pas d’outils d’éditions de code ou de débogage comme ceux que l’on trouve dans un environnement IDE. On ne peut pas naviguer dans le code en effectuant un ctrl-clic sur les dépendances. Cette limitation, combinée à la complexité de la programmation, rendait très difficile l’entretien ou la bonification du code.
Pour simplifier la maintenance, l’équipe avait entrepris de recopier tout le code Postman dans un fichier monolithique, déployé avec Node.js. Cette solution ne servait qu’à développer de nouvelles fonctionnalités et à corriger des bogues. Il fallait, pour chaque ajout ou correction dans Node.js, s’assurer de recopier manuellement les parties modifiées vers Postman.
Description de la première refactorisation
Puisque la solution Postman était découpée non seulement en collections, mais aussi en modules, l’aspect monolithique de la solution Node.js rendait la comparaison et la synchronisation des deux solutions assez ardue. Nous avons donc opté pour la refactorisation du code Node.js en le divisant en modules, pour tenter de calquer le plus possible la structure établie dans Postman. Pour chaque requête, nous avons écrit trois modules : la prérequête, la requête et la postrequête représentant respectivement les onglets Pre-request Script, Body et Tests de Postman. Nous avons placé ces requêtes dans des répertoires reflétant les collections de Postman. Nous avons également développé un module émulant les fonctionnalités de Postman: la gestion de variables, les valeurs aléatoires, la gestion des identifiants, les objets de requêtes et les objets de réponse, etc.
Ainsi, il est devenu beaucoup plus facile de naviguer dans le code et de le tester.
Toutefois, nous devions toujours composer avec certaines contraintes :
La maintenance de code à deux endroits, quoique facilité par la structure commune, reste vulnérable aux erreurs d’inattention.
Le code, non protégé, peut être modifié par inadvertance.
Le rapport d’exécution n’est disponible que dans le texte du journal (log).
L’utilisateur doit fouiller dans les logs pour trouver les erreurs.
L’absence de Git; nous utilisons la version autonome (standalone) gratuite, ce qui complique le versionnement. Même si on versionne la solution Node.js, la solution Postman n’a de version que dans le nom qu’on lui donne.
La convivialité de la manipulation des fichiers CSV étant limitée, l’utilisateur optait pour un fichier de données au format Excel qu’il devait transformer en CSV afin de l’intégrer dans Postman.
Le module Collection Runner de Postman n’est pas simple d’accès.
L’utilisateur doit copier les données recueillies lors d’une étape, pour les coller dans un fichier de données servant à la deuxième étape (i.e qu’il doit récupérer le numéros de client pour la création d’une soumission).
Au-delà de la solution Postman, nous possédions maintenant un outil Node.js entièrement fonctionnel et sensiblement bien découpé. Alors…
Comment rendre cette solution autonome?
Comment abandonner l’utilisation de Postman et ne plus avoir à maintenir le code à deux endroits?
Pour des raisons de sécurité et de coûts, il n’était pas possible de déployer cette nouvelle solution en tant qu’application Web. Il n’était pas envisageable non plus de fournir le code source aux utilisateurs en les invitant à déployer l’application Node.js localement.
L’environnement Electron
Lors de nos recherches, nous avons découvert Electron, un environnement qui permet de créer des applications de bureau (desktop application) écrites en JavaScript. Electron utilise Chromium et Node.js. C’est comme si nous déployions une application Node.js et que nous interagissions avec elle dans Chrome.
En d’autres mots, Electron permet d’écrire une application 100 % Web et de la convertir en application autonome (standalone). Cette application peut être déployée tant sur Mac que sur Windows ou Linux. Sans compter que la création d’installateurs pour ces plateformes est très simple.
Côté UI, au-delà du HTML pur, Electron est compatible avec React, Vue, ect.
L’environnement interagit également avec le système d’exploitation ce qui permet, entre autres, d’utiliser des fichiers locaux, de configurer des menus de l’application, d’utiliser des alertes, et d'assurer la persistance des données et des configurations.
De plus, Electron est au cœur de plusieurs applications largement utilisées, notamment :
Teams
Postman
VsCode
Skype
Slack
Quoi qu’il soit très robuste, constamment maintenu et possède une grande communauté d’utilisateurs,l’environnement comporte quand mêmes certains défauts :
L’application générée peut être volumineuse puisqu’elle encapsule Node.js et Chromium.
Chromium est reconnu pour sa grande consommation de mémoire et Electron hérite malheureusement de ce problème.
Des stratégies d’optimisation sont toutefois bien documentées en ce sens.
En mars 2023, Microsoft dévoilait sa réécriture de l’application Teams en délaissant Electron au profit de leur solution maison WebView2. Vous trouverez de plus amples renseignements ici.
En avril 2023, Electron dévoilait la mise en place d’une équipe spécifiquement axée sur la performance. Cette annonce, peut-être circonstancielle, témoigne malgré tout du sérieux de l’équipe de développement d’Electron.
Description de la solution autonome
Pour convertir notre solution Node.js, le code de base n’avait besoin d’aucune modification, hormis pour le « main » qui contient l’essentiel de la configuration et l’ajout des fichiers propres à Electron. La recherche de réponses à nos questions a été considérablement simplifiée grâce à la vaste communauté d’utilisateurs. En l’espace de deux jours, nous avons développé une preuve de concept fonctionnelle avec une interface utilisateur HTML conviviale.
Cette nouvelle solution surpasse les autres en raison des avantages suivants :
Une interface graphique minimaliste.
Le téléversement d’un seul fichier de données en format Excel sans conversion nécessaire.
L’exécution, présentée comme tableau contient plus d’informations, dont les messages d’erreurs (s’il y en a) à même la ligne d’exécution.
La génération de rapport en formats CSV, PDF et Excel.
La possibilité d’avoir une copie de tous les « payloads » de requêtes et de réponses sous forme de fichiers distincts dans le répertoire du rapport.
Un seul code source à entretenir.
Un versionnement concret avec des numéros de version dans le menu About.
La distribution facilitée, en raison d’un seul installateur versionné.
La suite
N’étant plus contraints par les paradigmes de Postman, nous avons la possibilité de refactorer le code pour alléger sa structure et, à bien des endroits, pour accélérer les exécutions. Ce détachement complet de la solution Postman, rend possible le développement de nouvelles fonctionnalités. Nous planifions :
Une interface graphique permettant la génération 100 % aléatoire en fonction de pourcentages de probabilités.
Une interface graphique différente pour chaque type d’opération.
L’utilisation de React pour optimiser le UI.
L’orchestration programmatique du fichier de données, contenant des onglets pour chaque étape. Cela prévient les erreurs de manipulation susceptibles de se produire lors du transfert de données par copier-coller entre les étapes.
Pour notre offre de service, convertir la solution Postman en une application Electron était un choix logique. Nous avons gagné en efficacité dans la maintenance du code, dans l’ajout de nouvelles fonctionnalités et dans la distribution de l’application. Nous avons adapté facilement l’interface graphique pour répondre aux différents besoins des utilisateurs et nous ne sommes plus tributaires d’une application qui peut changer ses fonctionnalités à tout moment. De plus, si le déploiement d’une application Web se concrétisait, nous serions déjà entièrement compatibles.
Lorsque nous avons découvert Electron, nous avons vite convenu que nous nous trouvions devant la seule solution sérieuse de ce genre. Depuis, d’autres joueurs sont apparus, comme Tauri et React Native Desktop (développé par Microsoft).
Electron répond à nos attentes et à notre besoin. Son développement constant, les nombreux modules d’extension ainsi que les ressources d’aide disponibles renforcent notre conviction d’avoir fait le bon choix.