Supabase n’envoie pas automatiquement de notifications push lorsqu’un événement survient dans votre base de données. Il n’existe pas d’appel supabase.notifications.send(). Pour en envoyer une, vous devez construire toute la chaîne : trigger Postgres, Edge Function, identifiants FCM et APNs, tokens d’appareils et logique de sélection des destinataires.
Cette approche fonctionne et est documentée. Ce guide explique ce qu’elle implique ainsi qu’une alternative gérée. Pour Flutter, lisez le guide Flutter ; des guides anglais existent aussi pour React Native, Expo, Capacitor, iOS et Android.
Ce qu’il faut pour envoyer un push
Chaque push nécessite quatre éléments : un token d’appareil, un emplacement pour le stocker, un trigger qui décide de l’envoi et un service de livraison — FCM pour Android, APNs pour iOS. Ici, nous relions ces éléments à Supabase.
La voie manuelle
Sans outil, un seul type de notification dans une application Supabase demande de :
- Stocker les tokens d’appareils, puis les enregistrer ou retirer à la connexion et à la déconnexion.
- Écrire un trigger Postgres sur la table concernée, tel que
AFTER INSERTouAFTER UPDATE. - Appeler une Edge Function depuis le trigger, souvent avec
pg_netou un webhook, car Postgres ne peut pas appeler FCM ou APNs directement. - Déterminer le destinataire dans la Function : un utilisateur, plusieurs via une jointure, ou tout le monde. La requête SQL ou la logique JS diffère pour chaque notification.
- Appeler FCM et APNs, adapter le payload à chaque plateforme et gérer échecs, tokens expirés et relances.
- Répéter les étapes 2 à 5 pour chaque notification et plateforme.
Chaque étape est simple isolément. C’est l’accumulation — une nouvelle Edge Function et une nouvelle requête de destinataires par notification — qui crée la charge de maintenance. En contrepartie, la chaîne reste entièrement sous votre contrôle.
La voie gérée
Entrig remplace les étapes 2 à 5 par de la configuration. Une notification comprend :
- Trigger : la table et l’événement (
INSERT,UPDATE,DELETE), avec condition éventuelle. - Users : le mode de recherche des destinataires : Direct (clés étrangères vers un utilisateur), Indirect via Join Table (diffusion via une table de jointure) ou Broadcast (tous les utilisateurs, filtrables).
- Message : titre, corps et champs de payload, avec des
{{placeholders}}provenant de la ligne ayant déclenché l’événement.
À l’enregistrement, Entrig génère et installe le trigger et la fonction Postgres dans le projet Supabase. Vous n’avez donc aucune Edge Function à écrire ou déployer. Côté client, le SDK s’initialise avec une clé API et enregistre l’appareil pour l’ID utilisateur ; Entrig assure la livraison vers FCM et APNs.
Ce qui reste nécessaire
Un service géré ne supprime pas les exigences propres aux plateformes. Dans les deux cas, vous devez :
- Créer un projet Firebase et générer le JSON de compte de service Android.
- Obtenir une clé d’authentification APNs pour la livraison iOS native.
- Activer les capacités push et les modes en arrière-plan dans le projet iOS.
- Demander la permission de notifications et gérer les taps et liens profonds.
- Conserver dans la base un ID utilisateur identique à celui utilisé pour enregistrer l’appareil.
Développement maison ou Entrig
| Maison | Entrig | |
|---|---|---|
| Nouvelle notification | SQL, requête de destinataires, Edge Function et déploiement | Configuration dans le tableau de bord, active à l’enregistrement |
| Installation du trigger | Écrit et migré par vous | Généré et installé automatiquement |
| Backend | Function ou serveur à maintenir | Aucun backend à vous ; Entrig assure la livraison |
| Tokens | Stockage, renouvellement et nettoyage par vous | Le SDK les enregistre ; les tokens rejetés sont invalidés |
| Relances | Logique FCM/APNs à écrire | Les erreurs transitoires sont relancées automatiquement |
Guides par plateforme
Chaque guide construit le même chat de groupe et les mêmes trois notifications : arrivée d’un membre, nouveau message et nouveau groupe.