Vue d'ensemble de l'architecture
Architecture du système
Section intitulée « Architecture du système »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 │└─────────────────────────────────────────────────────────────────┘Composants clés
Section intitulée « Composants clés »Système de bootstrappers
Section intitulée « Système de bootstrappers »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.
Registre des collections
Section intitulée « Registre des collections »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.
Service en temps réel
Section intitulée « Service en temps réel »La synchronisation en temps réel utilise le mécanisme natif LISTEN/NOTIFY de PostgreSQL :
- Une mutation de données se produit (insertion, mise à jour, suppression)
- Le backend émet un
NOTIFYsur un canal - Le
RealtimeServicereçoit la notification - Il diffuse le changement à tous les clients WebSocket connectés
- 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.
Registre de stockage
Section intitulée « Registre de stockage »À 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.
Carte des packages
Section intitulée « Carte des packages »| Package | Rôle | Utilisé par |
|---|---|---|
@rebasepro/types | Interfaces TypeScript pour les collections, les propriétés, les entités, les plugins | Tout |
@rebasepro/server-core | Initialisation du serveur backend, API REST, authentification, stockage, WebSocket | Backend |
@rebasepro/client | SDK client — Transport HTTP, WebSocket, authentification | Frontend |
@rebasepro/core | Framework React — Générateur, contrôleurs, formulaires, routes, hooks | Frontend |
@rebasepro/ui | Bibliothèque de composants UI autonome (Tailwind v4 + Radix) | Frontend |
@rebasepro/auth | Vues de connexion, hooks du contrôleur d’authentification, gestion des utilisateurs | Frontend |
@rebasepro/studio | Éditeur de collection, console SQL, console JS, éditeur RLS, navigateur de stockage | Frontend |
@rebasepro/cli | CLI pour la génération de schéma, les migrations de DB, la génération de SDK | Outils de développement |
@rebasepro/formex | Gestion légère de l’état des formulaires React | Frontend |
@rebasepro/data_enhancement | Plugin d’auto-complétion de champ basé sur l’IA | Frontend |
@rebasepro/data_import_export | Importation et exportation CSV/JSON/Excel | Frontend |
@rebasepro/schema_inference | Détection automatique du schéma à partir des données de base de données existantes | Backend/CLI |
Flux de données
Section intitulée « Flux de données »Flux de lecture
Section intitulée « Flux de lecture »- L’utilisateur ouvre une collection dans l’interface d’administration
- Le SDK client envoie
GET /api/data/:slug+ ouvre une souscription WebSocket - Le backend interroge PostgreSQL via Drizzle ORM
- Le transformateur de données désérialise les enregistrements de la base de données au format d’entité
- La réponse est envoyée au frontend, les composants se rendent
- WebSocket maintient la vue synchronisée en temps réel
Flux d’écriture
Section intitulée « Flux d’écriture »- L’utilisateur modifie une entité dans le formulaire
- Les rappels
beforeSaves’exécutent (validation, transformation) - Le SDK client envoie
PUT /api/data/:slug/:id - Le backend sérialise les valeurs, exécute
UPDATEde Drizzle - Les rappels
afterSaves’exécutent (effets secondaires) - La diffusion
NOTIFYdéclenche la mise à jour WebSocket vers tous les clients - Si l’historique est activé, un instantané est enregistré
Prochaines étapes
Section intitulée « Prochaines étapes »- Schéma comme Code — L’approche TypeScript-first
- Vue d’ensemble du Backend — Configuration du serveur
- Collections — Définissez votre schéma de données