Le Compte Asso et ses aspects techniques, un article rédigé par Glenn CARROY, membre de la #SynalTeam.
Le Compte Asso et son architecture technique
Chez Synaltic, en plus des projets Data déjà bien portés par nos équipes de Data Intégration et de Business Intelligence ; nous réalisons également des applications web sur mesure. Depuis quelques années, Synaltic est un acteur majeur de la dématérialisation des services d’informations liés aux associations. La DJEPVA , placée sous l’autorité du Ministre de l’Education nationale, de la jeunesse et des sports est cliente depuis 2017. Elle nous a chargé de développer un portail de services de la vie associative : Le Compte Asso.
Pour en savoir plus sur les fonctionnalités du site officiel de gestion des associations (LCA) :
Découvrir Le Compte Asso
Le Compte Asso possède à présent un site vitrine permettant de consulter les informations et d’effectuer les démarches administratives de vos associations :
Architecture Technique
Synaltic réalise cette application en javascript en s’appuyant sur le Framework Nuxt JS pour le frontend et sur un socle Node JS pour le backend, le tout avec une base MongoDB. Une version simplifiée de notre architecture micro-services est présentée dans la figure ci-dessous.
Un seul docker Mongo nous permet de gérer l’ensemble de nos bases. Pour l’essentiel, nous en utilisons 3 : une pour l’authentification des utilisateurs (gérée par le auth-server), une pour l’administration des subventions (gérée par le RDS-server) et une pour la gestion des différentes démarches proposées par LCA (gérée par LCA-server).
De plus amples informations sur les relations entre les bases sont exposées dans l’article décrivant les fonctionnalités de LCA.
Le point d’entrée du site est un serveur NGINX permettant les différentes redirections vers les services concernés. Ainsi, chaque interaction avec l’interface client passe par le NGINX pour ensuite être redirigée vers le gateway proxy. Ce proxy s’assure non seulement de la redirection vers le serveur concerné par la route qui est appelée mais également de “dicter” aux différents serveurs qu’elles sont les middlewares qu’ils vont devoir exécuter en fonction de la route interrogée.
Chaque serveur possède également son propre système de gestion des erreurs et l’application est également connectée à Sentry afin que le pôle DEV puisse plus facilement traquer les erreurs qui peuvent survenir en production.
En local, l’ensemble des développements est réalisé sur une architecture micro-services dans un environnement Docker. Le code est alors poussé sur Gitlab et doit passer un ensemble de tests industrialisé via un pipeline CI/CD.
N’hésitez pas à consulter les ressources suivantes :
- Un webinaire en ligne sur l’automatisation et les pipelines CI/CD.
- Un article expliquant l’industrialisation de nos tests.
- Une présentation de l’évolution de nos processus de développement.
[…] Lire la suite » […]