Aller au contenu

Vue d'ensemble de l'architecture

Rebase est une plateforme full-stack composée de quatre couches :

┌─────────────────────────────────────────────────────────────────┐
│ Frontend Layer │
│ React Admin UI • Custom Views • Plugins • Your App │
│ @rebasepro/core • @rebasepro/ui • @rebasepro/studio │
└───────────────────────────┬─────────────────────────────────────┘
│ HTTP + WebSocket
┌─────────────────────────────────────────────────────────────────┐
│ Backend Layer │
│ Hono HTTP Server • REST API • Auth • Storage • WS │
│ @rebasepro/server-core │
└───────────────────────────┬─────────────────────────────────────┘
│ Drizzle ORM
┌─────────────────────────────────────────────────────────────────┐
│ Database Layer │
│ PostgreSQL • Tables • RLS Policies • Realtime sync │
└─────────────────────────────────────────────────────────────────┘

Le backend s’initialise via un système de bootstrappers basé sur des plugins. La logique spécifique à la base de données est découplée dans son propre package, et les bootstrappers gèrent l’initialisation de la base de données, l’authentification et les services internes.

import { createPostgresAdapter } from "@rebasepro/server-postgresql";
database: createPostgresAdapter({
connectionString: process.env.DATABASE_URL!
})

Les collections se résolvent automatiquement par rapport au bootstrapper configuré via le registre d’injection de dépendances interne.

Le BackendCollectionRegistry est l’index d’exécution de toutes les collections, de leurs tables PostgreSQL, de leurs énumérations et de leurs relations Drizzle. Il est rempli au démarrage à partir de vos définitions de collections.

La synchronisation en temps réel utilise le mécanisme natif LISTEN/NOTIFY de PostgreSQL :

  1. Une mutation de données se produit (insertion, mise à jour, suppression)
  2. Le backend émet un NOTIFY sur un canal
  3. Le RealtimeService reçoit la notification
  4. Il diffuse le changement à tous les clients WebSocket connectés
  5. Les composants React se re-rendent avec les nouvelles données

Pour les déploiements multi-instances (par exemple, Cloud Run avec plusieurs réplicas), fournissez une connectionString dans votre PostgresBootstrapper afin que tous les réplicas partagent la même connexion LISTEN.

À l’instar des pilotes, les backends de stockage sont enregistrés dans un registre. Vous pouvez avoir plusieurs fournisseurs de stockage (local, S3) et router différents champs de fichiers vers différents backends en utilisant storageId.

PackageRôleUtilisé par
@rebasepro/typesInterfaces TypeScript pour les collections, les propriétés, les entités, les pluginsTout
@rebasepro/server-coreInitialisation du serveur backend, API REST, authentification, stockage, WebSocketBackend
@rebasepro/clientSDK client — Transport HTTP, WebSocket, authentificationFrontend
@rebasepro/coreFramework React — Générateur, contrôleurs, formulaires, routes, hooksFrontend
@rebasepro/uiBibliothèque de composants UI autonome (Tailwind v4 + Radix)Frontend
@rebasepro/authVues de connexion, hooks du contrôleur d’authentification, gestion des utilisateursFrontend
@rebasepro/studioÉditeur de collection, console SQL, console JS, éditeur RLS, navigateur de stockageFrontend
@rebasepro/cliCLI pour la génération de schéma, les migrations de DB, la génération de SDKOutils de développement
@rebasepro/formexGestion légère de l’état des formulaires ReactFrontend
@rebasepro/data_enhancementPlugin d’auto-complétion de champ basé sur l’IAFrontend
@rebasepro/data_import_exportImportation et exportation CSV/JSON/ExcelFrontend
@rebasepro/schema_inferenceDétection automatique du schéma à partir des données de base de données existantesBackend/CLI
  1. L’utilisateur ouvre une collection dans l’interface d’administration
  2. Le SDK client envoie GET /api/data/:slug + ouvre une souscription WebSocket
  3. Le backend interroge PostgreSQL via Drizzle ORM
  4. Le transformateur de données désérialise les enregistrements de la base de données au format d’entité
  5. La réponse est envoyée au frontend, les composants se rendent
  6. WebSocket maintient la vue synchronisée en temps réel
  1. L’utilisateur modifie une entité dans le formulaire
  2. Les rappels beforeSave s’exécutent (validation, transformation)
  3. Le SDK client envoie PUT /api/data/:slug/:id
  4. Le backend sérialise les valeurs, exécute UPDATE de Drizzle
  5. Les rappels afterSave s’exécutent (effets secondaires)
  6. La diffusion NOTIFY déclenche la mise à jour WebSocket vers tous les clients
  7. Si l’historique est activé, un instantané est enregistré