Data fetching

Statut

Document de cadrage frontend — version initiale.

État actuel visible

Les frontends utilisent plusieurs modes d'accès données :

• Supabase JS côté dmv-public ;
• Supabase JS côté dmv_backoffice ;
• appels RPC Supabase ;
• requêtes directes .from(...) ;
• fetch vers REST Supabase dans le sitemap et certaines pages ;
• fetch vers APIs externes pour imports backoffice ;
• SWR ponctuel pour des documents ;
• future cible API Laravel documentée dans l'architecture.

Clients visibles

Application	Client données visible
dmv-public	lib/supabaseClient.ts avec NEXT_PUBLIC_SUPABASE_URL et NEXT_PUBLIC_SUPABASE_ANON_KEY.
dmv_backoffice	src/lib/supabase.js avec VITE_SUPABASE_URL et VITE_SUPABASE_ANON_KEY.

Ces clients utilisent des clés publiques. Les secrets de service ne doivent jamais être exposés côté frontend.

Principes

• Ne pas disperser les règles métier sensibles dans les composants.
• Garder les appels données lisibles et testables.
• Utiliser le cache seulement quand l'invalidation est maîtrisée.
• Préférer les requêtes côté serveur pour les pages SEO publiques quand c'est pertinent.
• Protéger les routes sensibles côté backend, pas seulement par UI.
• Gérer explicitement chargement, erreur et état vide.

Vision cible

La cible stratégique est que les actions métier sensibles passent par l'API Laravel centrale.

Dans cette cible :

• Supabase JS côté frontend doit être rationalisé ;
• les appels publics peuvent rester optimisés pour SEO ou données publiques si validé ;
• les mutations sensibles passent par des endpoints backend ;
• les services frontend encapsulent les appels API ;
• les erreurs API ont un format exploitable par l'UI.

SWR et cache

SWR est visible dans le gestionnaire de documents. Son usage peut être élargi si :

• les données sont relues souvent ;
• la clé de cache est claire ;
• l'invalidation est explicite ;
• les erreurs sont correctement affichées ;
• la donnée n'est pas trop sensible.

États à gérer systématiquement

• Chargement initial.
• Rechargement.
• Erreur technique.
• Donnée vide.
• Droit insuffisant.
• Action en cours.
• Succès ou confirmation.

Points à clarifier

• Convention de services API Laravel côté frontend.
• Stratégie de migration des RPC Supabase.
• Politique de cache par type de donnée.
• Gestion des erreurs normalisées.
• Données publiques pouvant rester accessibles en lecture directe.