# Outils et technologies

Nous documentons ici les raisons des choix d’outils, de technologies et de processus pour Mojaloop, ainsi que les liens et versions recommandés pour chacun.

CHOIX D’OUTILS

• Développement d’API
  • Open API 3.0 est utilisé pour le développement d’API (Swagger 2.0 auparavant).
  • ISTIO en tant que passerelle API (WSO2 est désormais obsolète avec Mojaloop v16.0.0 - Congo et IaC v5.0.0 et suivants) offre une plateforme d’entreprise pour intégrer API, applications et services web — localement et sur Internet. Il fournit à Mojaloop une couche de sécurité et un portail de développement.
• Circle-CI — Outil utilisé pour l’intégration et le déploiement continus. Il nous fallait un système de build et de tests en ligne pouvant fonctionner avec de nombreux petits projets et une équipe distribuée. Jenkins a été envisagé, mais il impose d’héberger un serveur et une configuration lourde. CircleCI permet une solution sans hébergement propre, démarrable sans coût et avec une configuration minimale. Nous pensions pouvoir commencer avec CircleCI et migrer plus tard si nécessaire — ce besoin ne s’est pas présenté.
• Dactyl — Nous devons pouvoir imprimer la documentation en ligne. Bien qu’on puisse imprimer des fichiers Markdown un par un, nous souhaitons regrouper les fichiers en un ensemble de documents PDF finaux, où une même page peut se retrouver dans plus d’un manuel. Dactyl (opens new window) est un outil open source maintenu de conversion Markdown vers PDF. Nous avions d’abord essayé Pandoc, mais il gérait mal les tableaux. Dactyl corrige cela et est plus flexible.
• DBeaver — DBeaver (opens new window) est un outil multi-plateforme gratuit pour développeurs, programmeurs SQL, administrateurs et analystes de bases de données. Il prend en charge les bases courantes : MySQL, PostgreSQL, MariaDB, SQLite, Oracle, DB2, SQL Server, Sybase, MS Access, Teradata, Firebird, Derby, etc.
• Docker — Le moteur de conteneurs Docker crée et exécute des conteneurs à partir de fichiers d'images Docker.
• Docker Hub sert à lier, construire, tester et pousser les dépôts de code Mojaloop. Nous devions prendre en charge l’exécution locale et cloud. Nous avons de nombreux microservices à configurations simples et spécifiques. Le moyen le plus simple de garantir le même comportement dans chaque environnement — du développement local au cloud jusqu’à la production hébergée — est de placer chaque microservice dans un conteneur Docker avec tous les prérequis nécessaires à son exécution. Le conteneur devient une unité fermée, sécurisée, préconfigurée et exécutable.
• Draw.io — Nous devons produire des schémas et diagrammes d’architecture pour la documentation avec un outil idéalement gratuit, compatible open source, multi-plateforme, vectoriel et matriciel, WYSIWYG, utilisable avec Markdown et simple. Nous avons évalué de nombreux outils : Visio, Mermaid, PlantUML, Sketchboard.io, LucidChart, Cacoo, Archi, Google Drawings. Draw.io correspond le mieux à nos besoins : gratuit, maintenu, simple, formats adaptés, intégration Dropbox et GitHub, multi-plateforme. Pour archiver nos diagrammes, nous sauvegardons deux copies — une en SVG (vectoriel) et une en PNG (matriciel). Nous utilisons le PNG dans la doc car il s’affiche directement sur GitHub. Le SVG sert de maître car il est éditable.
• ESLint — Dans le code JavaScript, nous utilisons ESLint (opens new window) comme guide de style et outil d’application du style.
• GitHub — GitHub (opens new window) est un service de dépôt de code très répandu, basé sur git, le standard des projets open source. Le choix de GitHub était donc naturel. Nous créons une story pour chaque travail d’intégration, des bugs pour les problèmes, et suivons les stories dans tout le pipeline pour des métriques fiables.
• Helm — Le gestionnaire de paquets Helm pour Kubernetes fournit des déploiements et configurations modélisés et permet de maîtriser la complexité globale.
• IaC — L’infrastructure as code (IaC) regroupe les outils et scripts pour déployer une plateforme Mojaloop au niveau de qualité souhaité, du développement, QA ou sandbox jusqu’à la préproduction ou une qualité de production étendue. Elle s’appuie sur les releases Mojaloop comme cœur et déploie tout l’écosystème nécessaire au fonctionnement d’un switch Mojaloop.
• Kafka — Cette technologie répond au besoin de messagerie à fort débit et volume tout en limitant les exigences matérielles.
• JavaScript — L’application Mojaloop est principalement écrite en JavaScript.
• Kubectl — Interface en ligne de commande pour exécuter des commandes sur les clusters Kubernetes.
• Kubernetes — Outil d’entreprise fournissant une couche d’abstraction, la gestion d’infrastructure et l’orchestration de conteneurs.
• Markdown — La documentation est un livrable du projet au même titre que le code : nous voulons la versionner, la revue, le commit et le suivi des changements comme le code. Nous voulons aussi une consultation en ligne simple sans ouvrir constamment un lecteur dédié. GitHub intègre Markdown, ce qui convient bien. Les mêmes fichiers servent au wiki et aux documents. Ils peuvent être revus au commit avec les mêmes outils et lus directement sur GitHub. Google Docs, Word et PDF ont été écartés car ces formats binaires se différencient mal. Inconvénient : Markdown n’autorise qu’un formatage simple — pas de tableaux complexes ni de polices variables — mais cela suffit lorsque la priorité est la clarté.
• Mojaloop Testing Toolkit (TTK) — Le Mojaloop Testing Toolkit (opens new window) est un outil couteau-suisse pour les activités Mojaloop, surtout pour les tests bout en bout, les démonstrations, le mock d’API et d’autres scénarios. Les collections de tests Mojaloop utilisent le ML TTK ; c’est l’outil privilégié pour les tests bout en bout, intégré aussi aux scripts de tests automatisés (TTK CLI dans l’IaC et autres environnements dev/qa).
• MySQLWorkbench — MySQL Workbench (opens new window) est un outil visuel unifié pour architectes, développeurs et DBA. Il couvre la modélisation, le développement SQL et l’administration (configuration serveur, utilisateurs, sauvegardes, etc.). Disponible sous Windows, Linux et macOS.
• NodeJS — Environnement d’exécution JavaScript basé sur le moteur V8 de Chrome qui exécute Mojaloop. NodeJS convient aux microservices simples et dispose d’un vaste écosystème de bibliothèques open source. Les performances sont correctes ; les composants Node ne montent pas beaucoup en vertical, mais nous prévoyons de scaler horizontalement, ce qu’il gère bien. Le code Interledger d’origine et le prototype de niveau un étaient en NodeJS. La plupart des équipes utilisaient déjà Node, ce qui a motivé ce choix. Dans le code NodeJS, nous utilisons Standard (opens new window) comme guide et application du style.
• NPM — Gestionnaire de paquets pour Mojaloop, le JavaScript étant le langage par défaut.
• Percona pour MySQL — Ces outils servent de SGBDR pour assurer haute performance et fonctionnalités de niveau entreprise au système Mojaloop. Il nous fallait un backend SQL compatible open source et scalable en production ; nous avons choisi MySQL.
• Postman — Application Google Chrome pour interagir avec des API HTTP. Elle offre une interface conviviale pour construire des requêtes et lire les réponses.
• Rancher 2.0 — La gestion, le provisionnement et la supervision de l’infrastructure sont assurés par Rancher 2.0, plateforme Kubernetes d’entreprise pour gérer déploiements et clusters sur cloud et sur site. Rancher facilite pour les équipes DevOps le test, le déploiement et l’exploitation de Mojaloop où qu’il tourne.
• Slack — Slack sert à la communication interne d’équipe, en partie parce que plusieurs équipes l’utilisaient déjà et le préféraient au courriel pour rester léger.
• SonarCloud — Nous avions besoin d’un tableau de bord en ligne sur la qualité du code (taille, complexité, problèmes, couverture) agrégeant tous les dépôts. SonarCloud pour Mojaloop est gratuit avec un peu de configuration. Il propose aussi des contrôles sur les pull requests et des notes selon les quality gates.
• SourceTree — Sourcetree (opens new window) simplifie le travail avec les dépôts Git pour se concentrer sur le code. Visualisation et gestion via une interface graphique Git. Chaque développeur reste libre de son outil, dans le respect des recommandations GitHub générales.
• Visual Studio Code — Visual Studio Code (opens new window) est un éditeur orienté développement et débogage d’applications web et cloud modernes. Gratuit et disponible sur Linux, macOS et Windows.
• ZenHub — Il nous fallait une gestion de projet légère et cloud pour équipes distribuées, avec epics, stories, bugs et un tableau projet simple. Les offres en ligne VS et Jira ont été envisagées. Pour une petite équipe distribuée, un service en ligne convenait mieux. Pour un projet open source, nous voulions éviter les coûts récurrents d’un serveur dédié. Une intégration forte avec GitHub était importante ; suivre le travail par microservice avec ce microservice était très utile. Jira et VS apportaient plus de lourdeur que nécessaire pour cette taille de projet et s’intègrent moins bien à GitHub. ZenHub nous a permis de démarrer tout de suite. Inconvénient : pas de diagrammes de flux cumulatif ni de suivi du nombre de stories plutôt que des points — nous le faisons manuellement avec une feuille de calcul mise à jour quotidiennement et publiée sur le canal Slack « Project Management ».

CHOIX TECHNOLOGIQUES

• Développement agile — Méthodologie utilisée pour piloter le projet. Les exigences doivent être affinées au fil du développement ; nous avons préféré l’agile au waterfall ou au lean.
• APIs — Pour limiter la confusion due à de nombreux microservices changeants, nous utilisons des API fortement définies conformes à notre modèle REST pragmatique. Les API sont définies avec OpenAPI. Les équipes documentent leurs API avec Swagger v2.0 ou RAML v0.8 pour tester, documenter et partager automatiquement. Swagger est légèrement privilégié grâce aux outils gratuits. Mule utilisera RAML 0.8. Swagger peut être converti automatiquement en RAML v0.8, ou manuellement en RAML v1.0 pour plus de lisibilité.
• Tests automatisés — La majorité des tests sont automatisés pour faciliter la régression. Voir la stratégie de tests automatisés et les métriques de qualité du code.
• Hébergement — Mojaloop est conçu pour être agnostique vis-à-vis de l’infrastructure ; il est pris en charge sur AWS, Azure et en installation sur site.
• Interledger — Mojaloop avait besoin d’un protocole de transport léger, ouvert et sécurisé pour les fonds. Interledger.org (opens new window) répond à ce besoin et permet de se connecter à d’autres systèmes. Les blockchains ont aussi été envisagées, mais elles envoient des messages très volumineux, difficiles à livrer de façon fiable sur des infrastructures fragiles. De plus, l’anonymat fort des blockchains ne correspond pas à un objectif du projet : pour la lutte contre la fraude, les autorités réglementaires doivent pouvoir consulter les données de transferts par compte et par personne.
• Open source — L’ensemble du projet est publié en open source conformément aux principes Level One Project (opens new window). Tous les outils et processus doivent être compatibles open source et favoriser les projets sous licence Apache 2.0 sans contraintes de licences restrictives pour les développeurs.
• Système d’exploitation — Windows est très répandu dans les pays cibles, mais nous avions besoin d’un OS sans frais de licence et compatible open source : nous utilisons Linux. Nous ne dépendons pas d’une distribution particulière ; nous nous basons sur Amazon Linux de base. Dans les conteneurs Docker, Alpine Linux (opens new window) est utilisé.
• Microservices — L’architecture doit se déployer et scaler facilement, avec des composants remplaçables ou mis à jour simplement ; elle est donc découpée en microservices.
• Scaled Agile Framework — Quatre équipes de développement initiales étaient géographiquement séparées. Pour garder la première phase du projet sur les rails, le Scaled Agile Framework (SAFe) (opens new window) a été choisi. Le travail est découpé en program increments (PI) d’environ quatre sprints de deux semaines. Comme pour les sprints, chaque PI a des objectifs démontrables définis en réunion de PI.
• Services — Les microservices sont regroupés et déployés en quelques services (DFSP, annuaire central, etc.). Chacun dispose d’interfaces simples, de scripts de configuration, de tests et de documentation.
• Modélisation des menaces, de la résilience et de la santé — Le code Mojaloop échange de l’argent dans des environnements à infrastructure très instable ; il doit donc être sécurisé, résilient, exposer facilement son état de santé et tenter automatiquement d’y revenir.
• USSD — Les smartphones ne représentent qu’environ 25 % du marché cible et ne sont pas actuellement pris en charge par la plupart des services de transfert d’argent ; nous avons besoin d’un protocole fonctionnant sur les téléphones basiques. Comme M-Pesa, nous utilisons USSD entre le téléphone et le fournisseur de services financiers numériques (DFSP).