Implémenter la logique métier avec Kafka et Spring Boot : production, consommation, tests et Dockerisation (4/6)

Bienvenue dans la quatrième partie de notre série de tutoriels sur l’intégration d’Apache Kafka dans une application moderne ! Dans la première partie, nous avons exploré l’architecture globale de notre application de messagerie sociale et posé les bases conceptuelles du projet. La deuxième partie nous a guidés dans la mise en place de l’environnement de développement avec Docker Compose pour MySQL et Kafka. Enfin, la troisième partie a posé les fondations de notre backend Spring Boot, en créant le modèle de données, l’accès à la base via JPA et les premiers endpoints REST.

Il est maintenant temps d’enrichir notre backend. Cette section est cruciale, car nous allons y implémenter la logique métier complète de notre application de messagerie, et surtout, intégrer Apache Kafka. Nous verrons comment notre backend peut produire des messages dans un topic Kafka, et comment il peut également en consommer pour des traitements asynchrones. Ce pas est essentiel pour exploiter pleinement la puissance d’une architecture distribuée et événementielle.

💡 Code source complet de l’exercice
Vous pouvez consulter et cloner le code source correspondant à ce tutoriel sur GitLab :
👉gitlab.com/springboot-kafka-social-lab/tag=v1.0.0
Ce tag v1.0.0 correspond à la version réalisée dans ce tutoriel.
Le projet continuera à évoluer, donc vous pouvez aussi consulter la branche main ou develop pour suivre les mises à jour ultérieures.

1. Logique métier et communication Kafka

Dans cette section, nous allons finaliser la logique métier de notre backend et y intégrer les mécanismes de communication avec Apache Kafka. Nous allons nous concentrer sur trois composants clés : le service métier MessageService, qui orchestrera la sauvegarde des messages et leur publication, ainsi que le producteur MessageProducer et le consommateur MessageListener dédiés à Kafka.

1.1. Service métier MessageService

Le service MessageService centralise la logique métier liée aux messages. Il est responsable de l’enregistrement des messages en base de données et de leur publication dans Kafka. C’est le point d’orchestration de ces deux actions fondamentales.

📄 Fichier : src/main/java/com/izonova/sociallab/service/MessageService.java

package com.izonova.sociallab.service;

import com.izonova.sociallab.kafka.MessageProducer;
import com.izonova.sociallab.model.Message;
import com.izonova.sociallab.repository.MessageRepository;
import org.springframework.stereotype.Service;

import java.util.List;

/**
 * Service layer handling message persistence and Kafka publishing.
 */
@Service
public class MessageService {

    private final MessageRepository messageRepository;
    private final MessageProducer messageProducer;

    public MessageService(MessageRepository messageRepository, MessageProducer messageProducer) {
        this.messageRepository = messageRepository;
        this.messageProducer = messageProducer;
    }

    /**
     * Returns all messages from the database.
     */
    public List<Message> getAllMessages() {
        return messageRepository.findAll();
    }

    /**
     * Saves a new message and publishes it to Kafka.
     */
    public Message saveMessage(Message message) {
        Message saved = messageRepository.save(message);
        messageProducer.sendMessage(saved);
        return saved;
    }
}

💡 Explication

Le service injecte deux composants : MessageRepository pour l’enregistrement en base et MessageProducer pour la diffusion Kafka.
La méthode saveMessage() fait deux actions consécutives : la sauvegarde du message dans MySQL et l’envoi du message dans un topic Kafka.
La méthode getAllMessages() retourne simplement tous les messages persistés.

1.2. Producteur Kafka MessageProducer

Ce composant est chargé d’envoyer les messages dans un topic Kafka via Spring Kafka. C’est lui qui assure la liaison entre notre application et la plateforme de streaming.

📄 Fichier : src/main/java/com/izonova/sociallab/kafka/MessageProducer.java

package com.izonova.sociallab.kafka;

import com.izonova.sociallab.model.Message;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.kafka.core.KafkaTemplate;
import org.springframework.stereotype.Component;

/**
 * Kafka producer for sending messages to the configured topic.
 */
@Component
public class MessageProducer {

    private static final Logger logger = LoggerFactory.getLogger(MessageProducer.class);
    private final KafkaTemplate<String, Message> kafkaTemplate;
    private static final String TOPIC = "social.messages";

    public MessageProducer(KafkaTemplate<String, Message> kafkaTemplate) {
        this.kafkaTemplate = kafkaTemplate;
    }

    public void sendMessage(Message message) {
        logger.info("Producing message to Kafka: {}", message.getContent());
        kafkaTemplate.send(TOPIC, message);
    }
}

💡 Explication

KafkaTemplate est fourni par Spring pour envoyer des objets vers un topic.
Le message est envoyé sur le topic social.messages.
Les logs facilitent le debug lors du développement ou en production.
L’envoi se fait de manière asynchrone.

1.3. Consommateur Kafka MessageListener

Ce composant écoute les messages entrants sur le topic Kafka. Dans le cadre de ce tutoriel, il se contente de les afficher dans les logs, illustrant le mécanisme de consommation.

📄 Fichier : src/main/java/com/izonova/sociallab/kafka/MessageListener.java

package com.izonova.sociallab.kafka;

import com.izonova.sociallab.model.Message;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.kafka.annotation.KafkaListener;
import org.springframework.stereotype.Component;

/**
 * Kafka listener that reacts to new messages published to the topic.
 */
@Component
public class MessageListener {

    private static final Logger logger = LoggerFactory.getLogger(MessageListener.class);

    @KafkaListener(topics = "social.messages", groupId = "sociallab-group")
    public void listen(Message message) {
        logger.info("Consumed message from Kafka: {}", message.getContent());
    }
}

💡 Explication

@KafkaListener permet à Spring d’écouter automatiquement les messages d’un topic donné.
Le groupId identifie le groupe de consommation (peut être modifié si plusieurs instances).
Dans ce tutoriel, le listener se contente de logguer le message, mais il pourrait facilement déclencher d’autres actions (notifications, traitements, etc.).

📝 À retenir :
Cette partie du backend gère l’essentiel de la logique métier : sauvegarde, envoi dans Kafka, réception de messages. Grâce à l’intégration transparente de Spring Kafka, la communication entre services devient simple, robuste et extensible.

2. Configuration du backend Spring Boot

Pour que notre backend Spring Boot puisse fonctionner correctement avec MySQL et Kafka, une configuration spécifique est nécessaire. Nous allons la détailler dans le fichier application.properties, qui centralise les paramètres essentiels de l’application.

2.1. Fichier application.properties (configuration de base)

Le fichier application.properties permet de configurer les différents composants de l’application Spring Boot : la base de données, Kafka, et le comportement de JPA/Hibernate.
Il se trouve dans le dossier :
📄 src/main/resources/application.properties

Voici le contenu utilisé pour ce projet :

spring.application.name=springboot-kafka-social-lab

# MySQL DataSource
spring.datasource.url=${SPRING_DATASOURCE_URL:jdbc:mysql://localhost:3306/socialdb}
spring.datasource.username=${SPRING_DATASOURCE_USERNAME:user}
spring.datasource.password=${SPRING_DATASOURCE_PASSWORD:password}
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

# JPA/Hibernate
spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true

# Kafka
spring.kafka.bootstrap-servers=${KAFKA_BOOTSTRAP_SERVERS:localhost:9092}
spring.kafka.consumer.group-id=sociallab-group
spring.kafka.admin.auto-create=true

# Serializers (optionnel, mais conseillé pour clarté)
spring.kafka.consumer.key-deserializer=org.apache.kafka.common.serialization.StringDeserializer
spring.kafka.consumer.value-deserializer=org.apache.kafka.common.serialization.StringDeserializer
spring.kafka.producer.key-serializer=org.apache.kafka.common.serialization.StringSerializer
spring.kafka.producer.value-serializer=org.apache.kafka.common.serialization.StringSerializer

🧠 Explications section par section

🔹 Base de données MySQL

spring.datasource.url=...
spring.datasource.username=...
spring.datasource.password=...

La connexion à la base utilise une URL configurable via une variable d’environnement (avec fallback par défaut).
Les identifiants sont également injectables via un fichier .env ou en ligne de commande.
driver-class-name permet à Spring Boot d’utiliser le bon driver JDBC (MySQL 8+).

🔹 JPA & Hibernate

spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true

ddl-auto=update : crée automatiquement les tables si elles n’existent pas.
show-sql=true : affiche les requêtes SQL dans la console (utile pour debug).
format_sql=true : améliore la lisibilité des logs SQL.

🔹 Kafka

propertiesCopierModifierspring.kafka.bootstrap-servers=...
spring.kafka.consumer.group-id=...

bootstrap-servers : indique l’adresse du broker Kafka.
group-id : identifiant du groupe consommateur utilisé dans @KafkaListener.
admin.auto-create=true : autorise la création automatique de topics (utile en dev).
Les (de)sérialiseurs permettent de définir le format de transport (ici : chaînes de caractères, simple et efficace pour ce projet).

✅ Grâce à ce fichier, Spring Boot saura automatiquement comment :

se connecter à la base MySQL,
utiliser Hibernate pour créer les entités,
produire et consommer des messages Kafka,
configurer le tout dynamiquement via Docker ou un .env.

2.2. Variables d’environnement avec .env

Pour que notre application puisse interagir correctement avec MySQL et Kafka dans un environnement Dockerisé, nous utilisons un fichier .env. Il permet d’externaliser la configuration sans modifier le code source.

📍 Placez ce fichier à la racine du projet, au même niveau que docker-compose.local.yml.

📄 Exemple de fichier .env

# MySQL configuration
MYSQL_DATABASE=socialdb
MYSQL_ROOT_PASSWORD=root
MYSQL_USER=user
MYSQL_PASSWORD=password

# Spring Boot
SPRING_DATASOURCE_URL=jdbc:mysql://mysql:3306/socialdb
SPRING_DATASOURCE_USERNAME=user
SPRING_DATASOURCE_PASSWORD=password

# Kafka
KAFKA_BOOTSTRAP_SERVERS=kafka:9092

Pourquoi ne pas utiliser localhost ?

Dans un réseau Docker, chaque service (comme mysql ou kafka) est identifié par son nom de service défini dans docker-compose.yml.
Depuis le conteneur du backend, mysql et kafka sont donc accessibles par ces noms, et non par localhost.

Exemple : jdbc:mysql://mysql:3306/socialdb permet à l’application Spring Boot (dans Docker) de se connecter au conteneur MySQL.

3. Vérification du backend en local

Avant de passer à l’intégration du frontend ou au CI/CD, nous allons tester notre backend Spring Boot localement. L’objectif est simple : vérifier que l’API fonctionne, que les messages sont bien enregistrés en base et publiés dans Kafka, le tout dans un environnement local basé sur Docker.

3.1. Lancer MySQL et Kafka via Docker

Nous avons déjà préparé un fichier docker-compose.local.yml pour faciliter le lancement des services nécessaires au backend. Ce fichier démarre :

🗄️ Un conteneur MySQL avec la base socialdb
🧭 Un conteneur Zookeeper
📨 Un conteneur Kafka

⚙️ Démarrage via ligne de commande

Assurez-vous que Docker est bien lancé, puis exécutez la commande suivante à la racine du projet :

docker compose -f docker-compose.local.yml up -d

L’option -d signifie « détaché », c’est-à-dire que les conteneurs s’exécutent en arrière-plan.

Pour vérifier que tout fonctionne correctement :

docker compose -f docker-compose.local.yml ps

✅ Vous devriez voir les services mysql, zookeeper et kafka avec le statut Up.

🖥️ Alternative graphique avec Docker Desktop

Si vous préférez une interface graphique, Docker Desktop vous permet de :

Visualiser les conteneurs actifs
Inspecter les logs de chaque service
Redémarrer ou arrêter les services manuellement

C’est particulièrement utile pour les débutants ou pour diagnostiquer visuellement un problème sans passer par le terminal.

3.2. Lancer le backend Spring Boot

Vous pouvez exécuter l’application Spring Boot localement pour tester son bon fonctionnement. Deux méthodes sont possibles : via la ligne de commande ou un IDE.

✅ Option 1 : Démarrage via la ligne de commande

Depuis le dossier backend/, exécutez la commande suivante :

./gradlew bootRun

✅ Option 2 : Démarrage depuis un IDE (IntelliJ IDEA, VS Code…)

Ouvrez le dossier backend/ dans votre IDE.

Exécutez la classe principale SociallabBackendApplication.java (celle annotée avec @SpringBootApplication).

Observez la console : l’application devrait démarrer sur le port 8080, comme dans l’exemple ci-dessus.

3.3. Tester le bon fonctionnement du backend

Voici une séquence simple mais complète pour valider le bon fonctionnement du backend en local, après démarrage :

🟢 1. Vérifier que l’API est accessible

Effectuez une requête HTTP GET sur l’endpoint /api/messages.
Cela permet de vérifier que l’application est bien démarrée et que le mapping fonctionne.

Commande :

curl http://localhost:8080/api/messages

Résultat attendu :

Code HTTP 200 OK
Un tableau JSON (vide au départ)

🟢 2. Envoyer un message via l’API REST

Postez un nouveau message à travers l’endpoint POST /api/messages.
On teste ici la persistance (MySQL) + la publication dans Kafka.

Commande :

curl -X POST http://localhost:8080/api/messages
     -H "Content-Type: application/json"
     -d '{"content": "Bonjour Kafka !"}'

Résultat attendu :

Code HTTP 201 Created ou 200 OK
Réponse JSON contenant :
- id (auto-généré)
- content = « Bonjour Kafka ! »
- createdAt (timestamp ISO)

🟢 3. Vérifier la base de données MySQL

Connectez-vous à MySQL et vérifiez que le message a bien été inséré.

Commande :

docker exec -it <nom_du_conteneur_mysql> mysql -u user -p

(Saisir le mot de passe : password)

Puis dans MySQL :

USE socialdb;
SELECT * FROM messages;

Résultat attendu :

Le message apparaît dans la table avec son ID et sa date.

🟢 4. Vérifier que Kafka a bien reçu le message

Regardez la console du backend. Vous devriez voir ces logs apparaître :

Producing message to Kafka: Bonjour Kafka !
Consumed message from Kafka: Bonjour Kafka !

Cela confirme que :

Le message a été envoyé au topic Kafka (MessageProducer)
Il a été consommé (MessageListener)

4. Lancement du backend sur Docker

Jusqu’à présent, nous avons testé notre backend localement, que ce soit via la ligne de commande ou à partir de l’IDE. Nous avons vérifié que l’API répond correctement, que les messages sont bien enregistrés dans la base MySQL, et qu’ils sont publiés puis consommés dans Kafka.

➡️ Le backend est donc fonctionnel en environnement local.
Il est maintenant temps de le builder et de le déployer dans un conteneur Docker, pour pouvoir l’intégrer pleinement à notre environnement multi-services.

Pourquoi Dockeriser le backend ?

Docker nous permet de rendre notre application portable, isolée et reproductible. Cela facilite le déploiement dans différents contextes : développement, test, CI/CD ou cloud.
Avec Docker, nous allons :

Packager le backend dans une image auto-exécutable
Lancer ce service aux côtés de MySQL et Kafka
Simplifier les tests « end-to-end » avec un seul docker compose up

Objectif de cette section

Nous allons maintenant :

Créer un Dockerfile pour construire l’image Docker du backend
Modifier le fichier docker-compose.yml principal pour inclure ce backend

💡 À la fin de cette étape, vous pourrez lancer l’ensemble de l’application — backend, base de données, Kafka — avec une seule commande.

4.1. Dockerfile du backend

Avant de pouvoir exécuter notre backend dans Docker, nous devons lui apprendre comment se construire lui-même.
C’est exactement le rôle d’un fichier Dockerfile : il décrit étape par étape comment créer une image Docker prête à être lancée.

📦 Qu’est-ce qu’un Dockerfile ?

Un Dockerfile est un fichier texte qui contient les instructions nécessaires pour :

télécharger l’environnement de base (ex. : JDK)
copier le code source dans le conteneur
compiler le projet (ici avec Gradle)
lancer l’application

Cela permet de construire une image Docker personnalisée, 100 % autonome, pouvant être déployée partout.

🎯 Objectif

Nous allons ici créer un Dockerfile pour le backend Spring Boot, capable de :

Compiler le projet Java avec Gradle
Générer un fichier .jar prêt à être exécuté
Lancer ce .jar dans un conteneur léger

Ce Dockerfile suit une bonne pratique appelée multi-stage build, qui sépare la phase de compilation de la phase d’exécution. Cela réduit la taille finale de l’image, ce qui est idéal en production.

🧱 Contenu du Dockerfile

📄 Fichier : backend/Dockerfile

# --- STAGE 1: BUILDER ---
FROM gradle:8.8-jdk21 AS builder
WORKDIR /app

COPY build.gradle settings.gradle ./
COPY gradle ./gradle
COPY gradlew .
RUN chmod +x gradlew

# Pré-télécharge les dépendances
RUN ./gradlew dependencies --no-daemon

# Copie du code source
COPY src ./src

# Compilation du projet
RUN ./gradlew bootJar --no-daemon

# --- STAGE 2: RUNTIME ---
FROM openjdk:21-jdk-slim
WORKDIR /app

COPY --from=builder /app/build/libs/*.jar app.jar

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

🧠 Explication étape par étape

🏗️ Étape 1 : Compilation (builder)

FROM gradle:8.8-jdk21 AS builder
→ Image officielle avec Gradle + Java 21
WORKDIR /app
→ Dossier de travail dans le conteneur
COPY …
→ On copie d’abord les fichiers Gradle puis le code source
RUN ./gradlew dependencies
→ On télécharge les dépendances pour bénéficier du cache Docker (accélère les builds)
RUN ./gradlew bootJar
→ On compile le projet et on génère le fichier .jar dans build/libs/

🚀 Étape 2 : Exécution (runtime)

FROM openjdk:21-jdk-slim
→ Image minimale, plus légère que le builder (meilleur pour la prod)
COPY –from=builder …
→ On récupère uniquement le .jar compilé
EXPOSE 8080
→ Indique que l’application écoute sur le port 8080
ENTRYPOINT …
→ Démarre le backend Spring Boot avec java -jar

✅ Résultat

Grâce à ce Dockerfile, vous pouvez construire une image du backend avec cette commande (à exécuter dans le dossier backend/) :

docker build -t sociallab-backend .

Cela créera une image Docker nommée sociallab-backend, prête à être utilisée dans docker-compose.

4.2. Intégration du backend dans docker-compose.yml

Maintenant que notre backend Spring Boot peut être empaqueté dans une image Docker, nous allons l’intégrer dans le fichier docker-compose.yml principal du projet.
L’objectif est de pouvoir lancer tout l’environnement (MySQL, Kafka, backend) avec une seule commande, de manière fluide et reproductible.

📦 Rappel sur Docker Compose

Docker Compose est un outil qui permet de définir et exécuter des applications multi-conteneurs.
Grâce à un simple fichier docker-compose.yml, vous pouvez :

orchestrer plusieurs services
configurer leurs relations (réseau, dépendances)
injecter des variables via un fichier .env
automatiser les ports, volumes et builds

C’est la pierre angulaire d’un développement moderne et modulaire.

🧩 Ajout du service backend

Voici la version complète du fichier docker-compose.yml, incluant les services essentiels de notre projet :

version: '3.8' # Docker Compose file format version

services:
  mysql:
    image: mysql:8
    environment:
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    volumes:
      - mysql-data:/var/lib/mysql
    ports:
      - "3306:3306"

  zookeeper:
    image: bitnami/zookeeper:latest
    environment:
      - ALLOW_ANONYMOUS_LOGIN=yes
    ports:
      - "2181:2181"

  kafka:
    image: bitnami/kafka:3.5.1
    environment:
      - KAFKA_BROKER_ID=1
      - KAFKA_CFG_ZOOKEEPER_CONNECT=zookeeper:2181
      - KAFKA_CFG_LISTENERS=PLAINTEXT://:9092
      - KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://kafka:9092
      - ALLOW_PLAINTEXT_LISTENER=no
      - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=PLAINTEXT:PLAINTEXT
      - KAFKA_ENABLE_KRAFT=no
    depends_on:
      - zookeeper
    ports:
      - "9092:9092"

  backend:
    build: ./backend
    environment:
      SPRING_DATASOURCE_URL: ${SPRING_DATASOURCE_URL}
      SPRING_DATASOURCE_USERNAME: ${SPRING_DATASOURCE_USERNAME}
      SPRING_DATASOURCE_PASSWORD: ${SPRING_DATASOURCE_PASSWORD}
      KAFKA_BOOTSTRAP_SERVERS: ${KAFKA_BOOTSTRAP_SERVERS}
    depends_on:
      mysql:
        condition: service_healthy
      kafka:
        condition: service_started
    ports:
      - "8080:8080"

volumes:
  mysql-data:

🔍 Détail du service backend

build: ./backend
→ indique à Docker de construire une image à partir du Dockerfile situé dans le dossier backend.
environment
→ injecte les variables d’environnement nécessaires (base de données, Kafka) depuis le fichier .env.
depends_on
→ précise les dépendances du backend :
- attend que MySQL soit sain (service_healthy)
- attend que Kafka soit simplement lancé
ports: « 8080:8080 »
→ expose le port de l’API REST pour que vous puissiez y accéder via http://localhost:8080.

💡 Bonnes pratiques intégrées

Utilisation d’un volume persistant pour MySQL : vos données restent disponibles même après arrêt ou redémarrage des conteneurs.
Publicité correcte du broker Kafka (advertised.listeners) pour permettre la communication dans le réseau Docker.
Démarrage conditionnel du backend après les services critiques, ce qui évite les erreurs de connexion prématurée à MySQL ou Kafka.

🚀 Démarrer l’environnement complet

Une fois le fichier en place et vos variables .env correctement définies, vous pouvez lancer l’ensemble avec la commande suivante :

docker compose up --build -d

–build force la reconstruction de l’image du backend (utile après chaque modification)
-d exécute tous les conteneurs en mode détaché (arrière-plan)

4.3. Vérification du backend dans Docker

Une fois tous les services lancés avec Docker Compose, il est important de vérifier que le backend fonctionne comme prévu.

👉 Le principe reste identique aux tests en local.
Nous allons simplement nous assurer que :

l’API REST du backend répond bien sur le port 8080,
l’enregistrement de messages fonctionne (persistance en base MySQL),
les messages sont correctement envoyés sur Kafka.

🔁 Scénario de test complet

Accéder à l’API

Depuis votre navigateur ou avec curl, testez l’endpoint principal :

curl http://localhost:8080/api/messages

Vous devriez obtenir une liste vide ([]) si aucun message n’a encore été ajouté.

Envoyer un nouveau message

Utilisez une requête POST avec un message JSON :

curl -X POST http://localhost:8080/api/messages
  -H "Content-Type: application/json"
  -d '{"content": "Message envoyé via Docker"}'

Le message posté devrait apparaître dans la réponse JSON.

Vérifier la persistance

Vous pouvez ensuite re-tester l’API :

curl http://localhost:8080/api/messages

Le message posté devrait apparaître dans la réponse JSON.

Consulter les logs Kafka

Pour vérifier que le message a été bien publié dans Kafka, utilisez cette commande :

docker compose logs kafka

Dans les logs, vous devriez voir une trace de publication du message dans le topic concerné (via MessageProducer).

🧰 Outils complémentaires (facultatif)

Si vous utilisez Docker Desktop, vous pouvez visualiser tous les conteneurs en cours d’exécution, vérifier leurs logs, ou redémarrer individuellement chaque service.

De plus, des outils comme Kafdrop ou Kafka UI peuvent être ajoutés pour faciliter l’inspection des topics Kafka. Nous verrons cela plus loin.

Conclusion

Félicitations ! Vous avez franchi une étape majeure en intégrant Apache Kafka à votre backend Spring Boot et en enrichissant la logique métier de votre application. Vous savez désormais comment produire et consommer des messages, configurer votre environnement pour la communication Kafka, et valider son bon fonctionnement aussi bien en local que via Docker. C’est un pas significatif vers la construction d’applications distribuées robustes et réactives.

La suite dans la Partie 5

Dans le prochain article, nous nous concentrerons sur le frontend de notre application. Nous allons construire une interface utilisateur simple avec Vue.js pour interagir avec notre API Spring Boot, puis nous la dockeriserons pour l’intégrer pleinement à notre environnement multi-services. Préparez-vous à voir votre application prendre vie !

Pour rappel : la Partie 1 a posé les bases architecturales. La Partie 2 a couvert la mise en place de l’environnement Dockerisé. La Partie 3 a détaillé la structure de base du backend Spring Boot.

💬 Une question ou une remarque ?

Nous vous encourageons à poser vos questions en commentaire. Toute remarque ou suggestion est également la bienvenue !

1. Logique métier et communication Kafka

1.1. Service métier MessageService

💡 Explication

1.2. Producteur Kafka MessageProducer

💡 Explication

1.3. Consommateur Kafka MessageListener

💡 Explication

2. Configuration du backend Spring Boot

2.1. Fichier application.properties (configuration de base)

🧠 Explications section par section

🔹 Base de données MySQL

🔹 JPA & Hibernate

🔹 Kafka

2.2. Variables d’environnement avec .env

Pourquoi ne pas utiliser localhost ?

3. Vérification du backend en local

3.1. Lancer MySQL et Kafka via Docker

🖥️ Alternative graphique avec Docker Desktop

3.2. Lancer le backend Spring Boot

✅ Option 1 : Démarrage via la ligne de commande

✅ Option 2 : Démarrage depuis un IDE (IntelliJ IDEA, VS Code…)

3.3. Tester le bon fonctionnement du backend

🟢 1. Vérifier que l’API est accessible

🟢 2. Envoyer un message via l’API REST

🟢 3. Vérifier la base de données MySQL

🟢 4. Vérifier que Kafka a bien reçu le message

4. Lancement du backend sur Docker

Pourquoi Dockeriser le backend ?

Objectif de cette section

4.1. Dockerfile du backend

📦 Qu’est-ce qu’un Dockerfile ?

🎯 Objectif

🧱 Contenu du Dockerfile

🧠 Explication étape par étape

✅ Résultat

4.2. Intégration du backend dans docker-compose.yml

📦 Rappel sur Docker Compose

🧩 Ajout du service backend

🔍 Détail du service backend

💡 Bonnes pratiques intégrées

🚀 Démarrer l’environnement complet

4.3. Vérification du backend dans Docker

🔁 Scénario de test complet

🧰 Outils complémentaires (facultatif)

Conclusion

La suite dans la Partie 5

💬 Une question ou une remarque ?

Rejoignez-nous !

Publications similaires

Pourquoi ne pas utiliser localhost ?

📦 Qu’est-ce qu’un Dockerfile ?