1.2.1 Conception de l'architecture
L’architecture de cette PSL est basée sur des Single Page Application (SPA) et des micro-services (wikipedia)
Le découpage des fonctionnalités de ma PSL en livrables applicatifs WEB est naturel :
- une application publique par démarche (au sens applicatif du terme)
- une application interne par typologie d’utilisateurs (un éditeur pour les concepteurs, une administration pour les exploitants…)
Côté BACK, le principe des micro-services prévaut. Ainsi, le découpage des fonctionnalités est piloté par la séparation des données dans des bases différentes de par
- leur nature qui impose une technologie différente pour leur persistence :
- les données relationnelles sont stockées dans une base de données relationnelle (si le besoin s’en fait sentir un jour)
- les fichiers de moins de 16Mo sont stockés dans une base de données MongoDB (brouillons et paramètres d’une application de démarche)
- les fichiers de plus de 16Mo sont stockés dans une base de données MongoDB+GridFS (documents générés par le back ou pièces jointes)
- les données de référentiel sychronisés quotidiennement depuis des sources disponibles sur Internet sont stockées en mémoire dans le micro-service concerné (43,5Mo)
- leur usage
- visibilité/sécurité : le paramétrage du visuel d’une application de démarche est chargé dans le navigateur de l’utilisateur alors que le paramétrage des documents générés et du routage de ces derniers vers les partenaires/destinataires ne doivent pas être visibles des usagers.
- cache : les données de référentiel, les paramètres publics d’une application de démarche et les paramètres internes ne sont modifiables que depuis les applicatifs de la zone d’administration et leur lecture se fait à travers un cache