Zenovay est construit comme un système distribué de quatre services interconnectés, chacun optimisé pour son rôle spécifique. Comprendre comment ils fonctionnent ensemble est essentiel pour un développement et un débogage efficaces.
Vue d'ensemble des services
Notre plateforme se compose de quatre services principaux, chacun déployé indépendamment sur le réseau edge de Cloudflare :
- Landing (zenovay.com) — Site marketing et pages publiques. Export statique Next.js optimisé pour le SEO et le chargement rapide.
- Auth (auth.zenovay.com) — Service d'authentification centralisé. Gère la connexion, l'inscription, OAuth, SSO et les flux MFA.
- App (app.zenovay.com) — Tableau de bord analytique principal. Visualisation des données en temps réel, replay de session et gestion d'équipe.
- API (api.zenovay.com) — Services backend. Suivi des événements, traitement des données, facturation et intégrations tierces.
Communication inter-services
Les services communiquent via des patterns bien définis qui maintiennent la sécurité tout en permettant des expériences utilisateur fluides :
- Auth → App : Après une authentification réussie, les utilisateurs sont redirigés vers l'app avec des tokens sécurisés. L'état de session est synchronisé entre les onglets via l'API BroadcastChannel.
- App → API : Le tableau de bord effectue des requêtes authentifiées vers l'API en utilisant des tokens bearer. Toutes les requêtes analytiques, opérations de facturation et mutations de données transitent par ici.
- Tracking → API : Le script de suivi léger (<5 Ko) envoie des événements directement à l'API via des requêtes POST vers des endpoints résistants aux bloqueurs de publicités.
Flux de tokens
L'authentification suit un flux sécurisé entre les services :
- L'utilisateur se connecte sur auth.zenovay.com
- Supabase émet des tokens d'accès et de rafraîchissement
- Les tokens sont stockés dans des cookies httpOnly pour la protection XSS
- L'app valide les tokens à chaque requête via un middleware
- Les endpoints API vérifient les tokens bearer pour l'autorisation
- Les tokens de rafraîchissement pivotent automatiquement pour prévenir la réutilisation
Déploiement Cloudflare
Nous utilisons intensivement l'écosystème Cloudflare pour la performance et la fiabilité :
- Pages : Hébergement de sites statiques pour les frontends landing et app
- Workers : Fonctions API serverless exécutées à la périphérie
- KV : Stockage clé-valeur pour la limitation de débit, les verrous de session et le mapping d'endpoints personnalisés
- R2 : Stockage d'objets pour les avatars d'équipe et les enregistrements de session
- Turnstile : Protection anti-bots sans friction pour l'utilisateur
Architecture de base de données
Supabase (PostgreSQL) sert de base de données principale avec plusieurs décisions de conception clés :
- Multi-location basée sur les équipes : Toutes les données sont délimitées aux équipes, pas aux utilisateurs individuels. Cela active la collaboration par défaut.
- Row Level Security (RLS) : Les politiques au niveau de la base de données garantissent que les utilisateurs ne peuvent accéder qu'aux données qu'ils sont autorisés à voir.
- Abonnements en temps réel : Les données des visiteurs en direct sont diffusées vers les tableaux de bord via les canaux temps réel de Supabase.
- Triggers pour l'application : Les limites de plan et le suivi de l'utilisation sont appliqués au niveau de la base de données, pas seulement dans le code applicatif.