Flow Inbox et Notification
Inbox
Stack
- FastApi & Postgres
- Firebase Realtime Database
- Firebase FCM
Structure de la bd firebase realtime
- chats
- inboxs [ userId ] ( listes des users s'étant écrit au moins une fois )
- userId ( as inboxID )
- inbox [ userId ] ( liste des users ayant écrit au [userId] spécifique )
- userId ( liste des messages user ayant écrit au [userId] spécifique)
- objectMessage ( msg, createdAt, sendTo …. )
- notificationsTokens ( les deviceId’s pour les push notifications )
- tokens [ deviceId ] ( liste des deviceId’s )
- xxx……xx
Explication de la structure & flow
- user1 envoie un message à user2
- user1 a son userId dans inboxs
- user1 a également le userId du user2 dans son inbox + le
message
—---
- user2 a son userId ajouté dans inboxs
- user2 a egalement le userId du user1 dans son inbox + le
message
- si le user2 a son notificationToken definie il est notifier via
fcm ( facultatif )
- le corps de la notifications est envoyé vers la bd postgres
Notifications
Stack
- FastApi & Postgres
- Firebase Realtime Database
- Firebase FCM
Structure de la bd firebase realtime
- notifications
- usersTokens ( contient les devices token )
- tokens [ deviceId ]
- xxx…..xx
Explication de la structure & flow
- structure utile pour les campagnes ou cron notification
Docs ci dessus resumé par l’ia
Absolument. Voici le texte formaté pour être facilement copié-collé dans
un document Word, avec des titres, des listes à puces et des blocs de
code clairement définis.
Architecture de Messagerie et Notifications
Objectif
Intégrer un système de chat en temps réel et de notifications push dans
notre application existante en utilisant Firebase, tout en gardant la
logique métier principale sur notre backend FastAPI.
Stack Technique
● FastAPI & PostgreSQL (Source de vérité pour les
Backend Principal :
utilisateurs, les relations, etc.)
● Chat Temps Réel : Firebase Realtime Database (RTDB)
● Notifications Push : Firebase Cloud Messaging (FCM)
Partie 1 : Messagerie (Inbox)
Structure de données Firebase RTDB
Pour éviter la duplication de données et assurer la scalabilité, nous
adoptons une structure de données normalisée qui sépare les salons de
discussion des index utilisateurs.
chat_rooms : Contient les données complètes de chaque conversation.
user_chats : Un index léger pour chaque utilisateur, listant ses
conversations et leurs métadonnées (dernier message, compteur de
non-lus).
{
// 1. Les conversations elles-mêmes
"chat_rooms": {
"room_12345": {
"metadata": {
"participants": { "user_id_1": true, "user_id_2": true },
"createdAt": 1678886400000,
"lastMessageText": "Salut, ça va ?",
"lastMessageTimestamp": 1678886401234
},
"messages": {
"message_abc": {
"senderId": "user_id_1",
"text": "Hello !",
"timestamp": 1678886400123
},
"message_def": {
"senderId": "user_id_2",
"text": "Salut, ça va ?",
"timestamp": 1678886401234
}
}
}
},
// 2. Un index par utilisateur pour trouver ses conversations
"user_chats": {
"user_id_1": {
"room_12345": {
"withUser": "user_id_2",
"lastMessageText": "Salut, ça va ?",
"lastMessageTimestamp": 1678886401234,
"unreadCount": 0
}
},
"user_id_2": {
"room_12345": {
"withUser": "user_id_1",
"lastMessageText": "Salut, ça va ?",
"lastMessageTimestamp": 1678886401234,
"unreadCount": 1
}
}
}
}
Avantages :
● Non-duplication des messages : Chaque message est stocké
une seule fois.
● Scalabilité : Gère nativement les conversations de groupe en
ajoutant des participants.
● Efficacité : L'affichage de la liste des "inbox" ne charge que les
métadonnées légères depuis user_chats.
● Fonctionnalités : Facilite l'implémentation des compteurs de
non-lus et des statuts "vu".
Flow de la Messagerie
Scénario : User1 envoie son premier message à User2.
1. Client (React Native - User1) : L'application appelle un endpoint du
backend pour initialiser la conversation.
○ Endpoint : POST /chat/initiate
○ Payload : { "recipientId": "user_id_2" }
○ Header : Authorization: Bearer <token_jwt_de_user1>
2.
3. Backend (FastAPI) :
○ Le backend vérifie si une conversation existe déjà entre les
deux utilisateurs (en consultant sa base PostgreSQL).
○ Si non :
■ Il génère un nouvel ID de salon (new_room_id).
■ Il utilise le SDK Admin Firebase pour créer les
structures initiales dans chat_rooms et user_chats.
■ Il persiste la relation (user_id_1, user_id_2) ->
new_room_id dans PostgreSQL.
○
○ Le backend renvoie le room_id à l'application cliente.
4.
5. Client (React Native - User1) :
○ Avec le room_id et authentifié auprès de Firebase, le client
écrit le message directement dans la Realtime Database.
○ Il écrit le message dans /chat_rooms/{roomId}/messages.
○ Il met à jour les métadonnées dans
/user_chats/user_id_1/{roomId} et
/user_chats/user_id_2/{roomId} (en incrémentant le
unreadCount pour user2).
6.
7. Notification (via Trigger Backend) :
○ L'écriture d'un nouveau message déclenche une Firebase
Function.
○ La fonction identifie le destinataire, récupère son token FCM
et lui envoie une notification push.
○ (Optionnel) Elle enregistre la notification dans la base
PostgreSQL pour l'historique.
8.
Partie 2 : Notifications (FCM)
Structure de données Firebase RTDB
Nous stockons les tokens FCM par utilisateur, puis par identifiant
d'appareil, pour gérer les connexions multi-appareils.
Generated json
{
"user_fcm_tokens": {
"user_id_1": {
"device_id_A": "fcm_token_pour_le_tel_A_de_user1...",
"device_id_B": "fcm_token_pour_la_tablette_B_de_user1..."
},
"user_id_2": {
"device_id_C": "fcm_token_pour_le_tel_C_de_user2..."
}
}
}
Flow de la Notification
1. Enregistrement du Token :
● Au démarrage, l'application React Native obtient un token FCM.
● Elle envoie ce token (avec un device_id unique) à un endpoint
dédié du backend : POST /notifications/register_device.
● Le backend FastAPI enregistre le token dans RTDB sous le bon
user_id et device_id.
2. Envoi d'une Notification (Ex: Campagne ou Cron) :
● Une action est déclenchée sur le backend FastAPI (ex: POST
/notifications/send_campaign).
● Le backend détermine les user_id cibles.
● Pour chaque user_id, il récupère tous ses tokens FCM depuis
RTDB.
● Il utilise le SDK Admin Firebase pour envoyer le message FCM à
la liste des tokens collectés.
