Contexte, expérimentations et premières orientations

Le projet s’appuie sur une démarche de co-construction dont les travaux sont en cours.
Le cahier des charges ainsi que la modélisation des données ne sont pas encore définis, mais certains besoins sont déjà identifiés : authentification, gestion des API, stockage, indexation, notifications, etc.
L’idée est d’effectuer les travaux préparatoires, par rapport à ce qui est préssenti, pour être rapidement en ordre de marche lorsque l’équipe de développement sera complétée et les fonctionnalités attendues précisées :

Expérimentations autour d'outils : API manager, Brokers.
Environnement de développement intégré : Mise en œuvre d'un environnement de développement avec un ensemble des services. Ces services sont paramétrés pour dialoguer entre eux. Le déploiement se réalise très facilement sur un serveur de test ou en local pour le développement. De nouveaux services peuvent être ajoutés facilement en fonction des besoins.
Authentification et intégration OpenId Connect (OIDC) : l'intégration OIDC a été testée de bout en bout et s'articule entre l'interface utilisateur, l'API manager et l'API ePortfolio qui a été initiée.
Interface utilisateur : le choix du framework n'est pas encore arrêté mais des travaux ont été réalisés autour des fonctionnalités temps réel, pour les notifications, et des web components pour la réutilisabilité des éléments d'interface utilisateur : https://github.com/avenirs-esr/authentication-webcomp
Site développeurs : un site de documentation, essentiellement à destination des développeurs a été rédigée, basé sur Github pages. Il contient les notes de synthèse concernant les expérimentations menées et des pistes de réflexion.
Il précise également les éléments permettant de fixer un cadre de développement : versionnage, gestion des commits, workflow, etc.
https://avenirs-esr.github.io/dev-doc/
API ePortfolio :Développement d'une première brique de l'API, basée sur Spring boot, Kafka, Apache Apisix et OIDC.
https://github.com/avenirs-esr/avenirs-api

Prospection autour des API managers

L’interropérabilité est au cœur du projet Avenirs ePortfolio. La mise à disposition et les interactions avec des API sont donc un élément central.

Cela implique des besoins en terme de :

Gestion du trafic.
Monitoring, alertes.
Autorisation/authentification, sécurisation des web services.
Gestion des déploiements, par exemple avec une stratégie de canary release, qui permet de tester les nouvelles fonctionnalités sur une population restreinte.

Pour traiter ces problématiques, une possibilité est d’utiliser un logiciel spécialisé : un API manager. les API managers s’interfacent en amont des API développées et apportent les fonctionalité nécessaires au traitement de flux entrants ou sortants.
Les principaux outils du marché on été expérimentés : https://avenirs-esr.github.io/dev-doc/apim-list/
Parmis ces outils Gravitee et Apache Apisix se sont démarqués. Des contacts ont été pris avec les commerciaux de ces deux produits et des tests plus poussés ont été réalisés autour de l’intégration OIDC pour l’authentification. Les coûts de licence donnent plutôt l’avantage à Apache Apisix mais une licence éducation est en cours d’élaboration du côté de Gravitee.

Les API managers ne sont pas encore courants dans les établissements mais la problématique est identifiée et leur intérêt semble faire consensus. Nous avons pu échanger sur ce sujet avec l’Université de Loraine qui utilise Gravitee pour gérer ses API.

Architecture - Modules principaux

Les bases de l’architectures ont commencé à être posées. Outre une séparation classique entre interfaces utilisateurs (frontend) et les APIs (backend), les principaux modules sont identifiés avec un découpage basé sur les grand domaines fonctionnels. Nous avons pu également échanger avec l’équipe technique PC-scol qui nous a recommandé de privilégier une architecture simple. Ils nous ont déconseillé de mettre en place une architecture de type micro-services car cela complexifie considérablement les traitements en introduisant des problématiques de synchronisation de données.

Schéma général des principaux modules

Environnement de développement / expérimentation architecture technique

L’objectif de ce projet est de constituer un environnement autonome et intégré et de commencer à travailler sur les bases d’une architecture technique : https://github.com/avenirs-esr/srv-dev
Il permet de déployer très rapidement, dans des conteneurs, l’ensemble des services sur un serveur de test ou localement pour les développeurs ou contributeurs.
Il est basé sur docker et docker-compose et actuellement, la liste des services déployés est la suivante :

Authentification/OIDC : CAS et OpenLdap.
Reverse proxy/serveur web : Apache. La partie serveur web héberge les pages d'exemples et d'expérimentation.
API Manager : Apache Apisix, 4 conteneurs : passerelle, dashboard, collecte et visualisation des métriques.
Broker : Apache Kafka, 3 conteneurs : API, interface utilisateur, paramétrage et coordination distribués.
API ePortfolio : version java basée sur Spring Boot et NodeJs pour les fonctionnalité asynchrone.

Expérimentation d’une architecture technique

Perspectives

Parmi la listes de travaux à mener ou initier à court terme un certain nombre de points ressortent prioritairement :

Interfaces utilisateurs :Commencer à définir les interfaces utilisateur, éventuellement en mode fil de fer, la cinématique et les cas d'usage. L'ergonomie, l'accessiblité, et d'un manière générale l'expérience utilisateur sont des élements essentiels et doivent être pris en compte le plus tôt possible dans la vie du projet. Cela permettrait également de commencer à travailler sur la notion de rôles utilisateurs.
Stockage/ indexation / cyle de vie des données : le stockage des traces, leur exploitation et conservation représentent un point central en termes fonctionnel et complexe d'un point de vue technique avec des contraintes liées au volume de données. Une modélisation, même partielle des objets manipulés est nécessaire pour pouvoir initier les travaux de ce module.
Log / Monitoring / collecte des usages : c'est également un point essentiel, en terme d'exploitation, afin de garantir un fonctionnement nominal de la plateforme. Il s'agit d'u module transversal à intégrer au développement des autres modules.