Aller au contenu principal

Stratégie RPC

Statut​

Document de cadrage data — version initiale.

Rôle​

Les RPC peuvent exposer des requêtes contrôlées, performantes et sécurisées directement au niveau PostgreSQL ou Supabase.

Elles doivent rester utilisées pour des besoins précis, pas remplacer la couche métier Laravel.

État actuel visible​

Les migrations Supabase historiques contiennent de nombreuses fonctions RPC, notamment autour de :

  • tags acteurs ;
  • quotas documents ;
  • documents acteurs ;
  • feature tabs ;
  • mur contributeur ou mur ville ;
  • favoris ;
  • publications personnelles ;
  • groupes ;
  • modération ;
  • settings ;
  • statistiques d'astuces.

Le code Laravel contient aussi des services qui semblent reprendre certaines responsabilités historiquement côté Supabase, par exemple autour des tags ou documents acteurs.

Cible stratégique​

La cible est :

  • API Laravel comme couche métier principale ;
  • RPC conservées seulement si elles apportent performance, sécurité ou atomicité ;
  • RPC documentées, testées et versionnées ;
  • aucun usage RPC opaque depuis un frontend sans gouvernance.

Bons cas d'usage RPC​

UsageJustification
Requête agrégée performanteÉviter plusieurs allers-retours.
Opération atomique simpleGarantir cohérence en base.
Lecture publique contrôléeExposer un résultat limité et filtré.
AnalyticsAgrégats ou vues spécialisées.

Mauvais cas d'usage RPC​

  • Logique métier complexe non testée côté backend.
  • Règles dupliquées entre Laravel et Supabase.
  • Accès direct à des données sensibles.
  • Fonction non documentée appelée par plusieurs frontends.
  • Contournement des autorisations Laravel.

Points à clarifier​

  • Liste officielle des RPC encore utilisées.
  • RPC à migrer vers services Laravel.
  • RPC à conserver pour performance.
  • Politique de tests et versioning des RPC.
  • Propriété entre équipe backend et base.