Persistance
Modèles JPA pour représenter des cours, des étudiants et leurs relations dans une base PostgreSQL.
Le projet en quelques mots
JWS suit une progression allant de la persistance de données à une application découpée en microservices qui communiquent entre eux.
Le dépôt rassemble quatre étapes : la modélisation de données avec JPA, la création de routes HTTP, une première chaîne de messages Kafka, puis EpiBazaar. Ce dernier propose le backend d'un jeu dans lequel un joueur parcourt une carte, collecte des ressources et interagit avec des boutiques.
Le sujet d'EpiBazaar définit un système complet. Le rendu conservé en implémente les fondations et une partie des échanges ; la page distingue donc le code présent des fonctionnalités qui restaient à terminer.
Une progression en quatre étapes
API REST
Routes Quarkus recevant des paramètres ou du JSON et renvoyant des réponses structurées avec des DTO.
Messagerie
Producteur, processeur et consommateur reliés par des canaux Kafka pour traiter un message de manière asynchrone.
EpiBazaar
Mise en commun de ces notions dans une application Quarkus découpée en microservices et organisée en couches.
Architecture visible dans le rendu
EpiBazaar est découpé en trois microservices : Item Producer, Inventory et Shop. Chacun expose ses propres routes REST et possède ses propres données, un quatrième module servant de bibliothèque partagée. Le seul échange Kafka effectivement relié dans le rendu va d'Item Producer vers Inventory lors du démarrage d'une partie. Les schémas détaillent d'abord le traitement interne d'une requête à travers les différentes couches, puis distinguent les appels HTTP synchrones du message asynchrone.
01
Traitement interne - Architecture en couches
Chaque requête traverse des composants aux responsabilités distinctes.
Resource REST
Reçoit la requête HTTP, lit ses paramètres et prépare la réponse JSON.
Service métier
Orchestre le cas d'usage et applique les règles du domaine.
Repository
Isole les opérations de lecture et d'écriture des modèles persistants.
PostgreSQL
Conserve les données propres au service concerné.
Ce découpage sépare l'interface HTTP, la logique métier et la persistance : chaque couche peut ainsi évoluer sans mélanger les responsabilités.
02
Appels synchrones - REST
Un client appelle directement les routes exposées par chaque service.
Client de l'API
Requêtes HTTP et réponses JSON
Item Producer
Démarre la partie, lit la carte et gère le joueur ainsi que ses déplacements.
PostgreSQL · données propresInventory
Conserve les ressources et remet l'inventaire à zéro sur réception d'une commande.
PostgreSQL · données propresShop
Crée, consulte et stocke les boutiques accessibles dans le jeu.
PostgreSQL · données propres
03
Message asynchrone - Kafka
Un seul parcours est câblé de bout en bout dans le code conservé.
Item Producer
ResetInventoryCommand
Kafka
Inventory
Shop reste accessible par REST et ne participe pas à ce flux Kafka dans le rendu conservé. Le message ci-dessus sert uniquement à réinitialiser Inventory lorsqu'une nouvelle partie démarre.
Ce qui est présent
Carte et joueur
Une route charge une carte encodée par répétitions, initialise la partie et le joueur, puis déclenche la remise à zéro de l'inventaire. D'autres routes renvoient les ressources, le joueur et son déplacement.
Boutiques
Le service Shop permet de lister les boutiques, d'en consulter une par son identifiant et d'en créer une avec persistance en base.
Persistance séparée
Les trois services possèdent leurs propres modèles et repositories. Des migrations SQL définissent les tables de départ de chaque module.
Périmètre restant
La collecte, la vente et les améliorations prévues dans le sujet ne forment pas des parcours complets dans ce rendu. Certains paramètres et points d'entrée sont absents ou commentés.
Un exemple concret : charger la carte
Une carte est lue depuis un fichier compact : un chiffre indique combien de fois répéter le type de terrain qui le suit. Le service transforme ce contenu en grille, l'enregistre et crée un joueur à la position de départ.
map = Files.readString(Paths.get(startRequest.getMapPath()))
.replace('\n', ';');
List<List<ItemAggregate.ResourceType>> newMap =
gameService.startNewGame(map);
playerService.startNewPlayer();
resetInventoryCommandEmitter.send(new ResetInventoryCommand());Bilan
Travail conservé
Le dépôt montre la construction progressive d'un backend Quarkus : modèles persistants, API REST, messages Kafka et découpage en couches. EpiBazaar est fonctionnel sur le périmètre réalisé dans le dépôt.
Ce que ce parcours m'a apporté
Ces exercices m'ont permis d'aborder les rôles respectifs d'une route HTTP, d'un service métier et d'un repository, puis de découvrir comment des services peuvent échanger sans s'appeler directement grâce à Kafka.