120 lines
4.8 KiB
Markdown
120 lines
4.8 KiB
Markdown
# Temps réel en développement (Kafka + WebSocket)
|
||
|
||
Ce guide permet de faire fonctionner les **notifications / présence / réactions / chat** en temps réel en environnement de développement.
|
||
|
||
## Architecture
|
||
|
||
```
|
||
Services métier → Kafka (topics) → Bridges → WebSocket → Client Flutter
|
||
```
|
||
|
||
- **Topics Kafka** : `notifications`, `chat.messages`, `reactions`, `presence.updates`
|
||
- **WebSocket** : `ws://<backend>/notifications/<userId>` (et `/chat/<userId>` pour le chat)
|
||
|
||
## 1. Démarrer Kafka en local
|
||
|
||
Un conteneur Kafka doit être joignable sur le **port 9092** depuis la machine où tourne Quarkus.
|
||
|
||
### Option A : Conteneur existant
|
||
|
||
Si vous avez déjà un conteneur Kafka (ex. ID `e100552d0da2...`) :
|
||
|
||
- Vérifiez que le port **9092** est exposé vers l’hôte :
|
||
```bash
|
||
docker port <container_id_or_name> 9092
|
||
```
|
||
- Si rien n’est mappé, recréez le conteneur avec `-p 9092:9092` ou dans un `docker-compose` :
|
||
```yaml
|
||
kafka:
|
||
image: apache/kafka-native:latest # ou quay.io/strimzi/kafka:latest, etc.
|
||
ports:
|
||
- "9092:9092"
|
||
# ... reste de la config (KAFKA_CFG_..., etc.)
|
||
```
|
||
|
||
### Option B : Lancer Kafka avec Docker (exemple minimal)
|
||
|
||
```bash
|
||
docker run -d --name kafka-dev -p 9092:9092 \
|
||
-e KAFKA_NODE_ID=1 \
|
||
-e KAFKA_PROCESS_ROLES=broker,controller \
|
||
-e KAFKA_LISTENERS=PLAINTEXT://0.0.0.0:9092,CONTROLLER://0.0.0.0:9093 \
|
||
apache/kafka-native:latest
|
||
```
|
||
|
||
(Adaptez l’image et les variables à votre setup si vous en utilisez un autre.)
|
||
|
||
### Depuis une autre machine / Docker
|
||
|
||
- **Quarkus sur l’hôte, Kafka dans Docker** : `localhost:9092` suffit si le port est mappé (`-p 9092:9092`).
|
||
- **Quarkus dans Docker, Kafka sur l’hôte** : utilisez `host.docker.internal:9092` (Windows/Mac) ou l’IP de l’hôte.
|
||
- Définir alors :
|
||
```bash
|
||
export KAFKA_BOOTSTRAP_SERVERS=localhost:9092
|
||
```
|
||
(ou `host.docker.internal:9092` selon le cas).
|
||
|
||
## 2. Démarrer le backend Quarkus (profil dev)
|
||
|
||
```bash
|
||
cd mic-after-work-server-impl-quarkus-main
|
||
mvn quarkus:dev
|
||
```
|
||
|
||
Le fichier `application-dev.properties` utilise par défaut `localhost:9092`.
|
||
En cas d’erreur de connexion Kafka au démarrage, vérifiez que Kafka écoute bien sur 9092 et que `KAFKA_BOOTSTRAP_SERVERS` pointe vers ce broker.
|
||
|
||
Logs utiles au démarrage :
|
||
|
||
- `[KAFKA-BRIDGE] Bridge démarré pour topic: notifications`
|
||
- Pas d’exception type `ConfigException` / « No resolvable bootstrap urls »
|
||
|
||
Quand une notification est publiée et consommée :
|
||
|
||
- `[KAFKA-BRIDGE] Événement reçu: type=... userId=...`
|
||
- `[WS-NEXT] Notification envoyée à <userId> (Succès: 1, Échec: 0)`
|
||
|
||
## 3. Configurer l’app Flutter (URL du backend)
|
||
|
||
Le client doit pouvoir joindre le **HTTP** et le **WebSocket** du même backend.
|
||
|
||
- **Émulateur Android** : souvent `http://10.0.2.2:8080` (puis WebSocket `ws://10.0.2.2:8080/notifications/<userId>`).
|
||
- **Appareil physique / même réseau** : IP de la machine qui fait tourner Quarkus, ex. `http://192.168.1.103:8080`.
|
||
- **Chrome / web** : `http://localhost:8080` si Flutter web et Quarkus sont sur la même machine.
|
||
|
||
Définir cette URL comme base API (elle est aussi utilisée pour le WebSocket) :
|
||
|
||
- Au run :
|
||
```bash
|
||
flutter run --dart-define=API_BASE_URL=http://<VOTRE_IP_OU_HOST>:8080
|
||
```
|
||
- Ou dans `lib/core/constants/env_config.dart` (valeur par défaut en dev).
|
||
|
||
Important : **pas de slash final** dans `API_BASE_URL` (ex. `http://192.168.1.103:8080`).
|
||
|
||
## 4. Vérifier que le temps réel fonctionne
|
||
|
||
1. **Connexion WebSocket**
|
||
- Se connecter dans l’app avec un utilisateur.
|
||
- Côté Flutter : log du type « Connecté avec succès au service de notifications ».
|
||
- Côté Quarkus : `[WS-NEXT] Connexion ouverte pour l'utilisateur: <userId>`.
|
||
|
||
2. **Notification (ex. demande d’ami / post)**
|
||
- Déclencher une action qui crée une notification (autre compte ou service).
|
||
- Côté Quarkus : `[KAFKA-BRIDGE] Événement reçu` puis `[WS-NEXT] Notification envoyée à ...`.
|
||
- Côté Flutter : la notification doit apparaître sans recharger (si l’écran écoute le stream temps réel).
|
||
|
||
3. **Si rien n’arrive**
|
||
- Kafka : le broker est-il bien sur le port 9092 ? `KAFKA_BOOTSTRAP_SERVERS` correct ?
|
||
- WebSocket : l’URL dans l’app est-elle exactement celle du backend (même hôte/port) ?
|
||
- CORS : pour Flutter web, le backend doit autoriser l’origine de l’app (déjà géré dans la config actuelle si vous n’avez pas changé l’origine).
|
||
|
||
## 5. Résumé des variables utiles (dev)
|
||
|
||
| Variable | Rôle | Exemple |
|
||
|----------|------|--------|
|
||
| `KAFKA_BOOTSTRAP_SERVERS` | Broker Kafka pour Quarkus | `localhost:9092` ou `host.docker.internal:9092` |
|
||
| `API_BASE_URL` (Flutter) | Base HTTP + WS du backend | `http://192.168.1.103:8080` |
|
||
|
||
Aucune régression fonctionnelle n’est introduite par ce guide : seules la configuration dev et le format des messages WebSocket (timestamp/type dans `data`) ont été alignés pour le client.
|