Skip to main content

Organisation d'un module

Caractéristiques du module

Les modules peuvent contenir des applications backend avec des services API REST ou des applications frontend et backend. Les technologies frontend peuvent être différentes :

Les interfaces clientes Web développées en Angular ou React sont stockées dans src/main/resources/META-INF/resources.

Structure

Chaque module a la structure suivante :

module/
README.md
src/main/java
ModuleMain.java
ModuleVerticle.java
src/main/resources
application.properties
src/main/resources/META-INF/resources
(code bundle HTML / Javascript de l'interface Web)

Comment ça fonctionne ?

Chaque module lance une application Quarkus qui inclut un serveur web intégré.

Ce serveur web est utilisé pour exposer des API REST ou d'autres points d'accès nécessaires pour interagir avec les fonctionnalités du module.

Le port par défaut sur lequel chaque module écoute varie selon sa configuration spécifique, afin d'éviter tout conflit dans un environnement multi-modules.

De plus, chaque module démarre un Verticle Vert.x pour souscrire aux événements sur le bus d'événements. Cela permet une communication asynchrone et décentralisée entre les modules, essentielle pour la gestion des interactions dans un environnement de microservices.

Démarrer le module

Le module peut être démarré comme un module classique Quarkus.

mvn quarkus:dev -DPROFILE=native

Conteneur

Le module peut être packagé sous forme de conteneur Docker avec Quarkus :

mvn package -DPROFILE=native

(voir plus de détail dans la partie développement)

Variables d'environnement

Tous les modules contiennent des fichiers de configuration permettant de paramétrer le module. Les fichiers de configuration peuvent être surchargés par des variables d'environnement.

Voici l'ordre des priorités

Gestion des priorités

  1. System Properties :

    • Les propriétés du système (ex. -Dproperty=value lors du démarrage) ont la plus haute priorité.
  2. Environment Variables :

    • Les variables d'environnement ont également une priorité élevée, juste après les propriétés du système.
  3. MicroProfile Config Sources :

    • Application Properties :
      • Les fichiers application.properties ou application-dev.properties sont des sources de configuration standard et ont une priorité moyenne.
    • Custom Config Sources :
      • Les sources de configuration personnalisées définies par l'utilisateur sont également de priorité moyenne, mais leur position dans la chaîne dépend de l'implémentation.
    • Config Profiles :
      • Les profils spécifiques dans les fichiers de configuration (comme application-dev.properties) ont la priorité la plus basse, mais peuvent remplacer les configurations standard selon le profil actif.

Plus d'information sont disponible dans la specification MicroProfile Config