Notifications

La plateforme est conçue pour alerter les utilisateurs en quelques secondes lors d'un événement critique (exemple: Cheval bloqué).

Canaux

1. In-App (Cloche)

   • Persistance : Sauvegardé en base de données (table notifications).
   • Temps-Réel : Livré via Websocket (événement camera:alert).
   • Service : NotificationService.

2. Email

   • Fournisseur : SMTP (Configurable via .env).
   • Usage : Rapports hebdomadaires, Alertes Critiques (si configuré).

3. SMS

   • Fournisseur : Twilio.
   • Usage : Alertes Critiques UNIQUEMENT (Coût élevé, l'utilisateur doit accepter).

4. Mobile Push

   • Fournisseur : Expo Push API / Google FCM.
   • Service : ExpoServerSdk.

Architecture Temps Réel

Le système utilise une architecture Pub/Sub robuste pour garantir la livraison fiable des notifications à travers les instances distribuées et lors des redémarrages.

Composants

1. Socket.IO Rooms :

   • Les utilisateurs s'abonnent à une "Room" dédiée lors de la connexion : socket.join('user_{userId}').
   • Cela remplace le suivi manuel des sockets et élimine les fuites de mémoire.

2. Redis Adapter :

   • Sert de bus de communication entre les instances backend.
   • Lorsqu'un nœud API émet une notification, il la publie sur Redis.
   • Tous les nœuds API reçoivent le message et le transmettent à leurs clients connectés participant à la Room cible.

Flux d'Événement

Résilience & Auto-Guérison

Le système est conçu pour gérer les redémarrages serveur de manière transparente :

1. Redémarrage Serveur : Les connexions sont coupées, la mémoire backend (Rooms) est effacée.
2. Reconnexion Client : Le socket.io-client frontend tente automatiquement de se reconnecter (stratégie de backoff).
3. Ré-abonnement : Sur l'événement connect, le frontend réémet immédiatement subscribeToNotifications.
4. Rétablissement : Le nouveau socket rejoint la room user_{id}, et les alertes temps réel reprennent instantanément.