Ir al contenido

Resumen de la Arquitectura

Rebase es una plataforma full-stack con cuatro capas:

┌─────────────────────────────────────────────────────────────────┐
│ 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 │
└─────────────────────────────────────────────────────────────────┘

El backend se inicializa a través de un sistema de inicialización basado en plugins. La lógica específica de la base de datos se desacopla en su propio paquete, y los inicializadores (bootstrappers) se encargan de la inicialización de la base de datos, la autenticación y los servicios internos.

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

Las colecciones se resuelven automáticamente contra el inicializador configurado a través del registro interno de inyección de dependencias.

El BackendCollectionRegistry es el índice en tiempo de ejecución de todas las colecciones, sus tablas PostgreSQL, enums y relaciones Drizzle. Se completa al iniciar a partir de sus definiciones de colección.

La sincronización en tiempo real utiliza el mecanismo nativo LISTEN/NOTIFY de PostgreSQL:

  1. Ocurre una mutación de datos (inserción, actualización, eliminación)
  2. El backend emite una NOTIFY en un canal
  3. El RealtimeService recibe la notificación
  4. Transmite el cambio a todos los clientes WebSocket conectados
  5. Los componentes de React se vuelven a renderizar con los nuevos datos

Para implementaciones multi-instancia (por ejemplo, Cloud Run con múltiples réplicas), proporcione una connectionString en su PostgresBootstrapper para que todas las réplicas compartan la misma conexión LISTEN.

Al igual que los controladores, los backends de almacenamiento se registran en un registro. Puede tener múltiples proveedores de almacenamiento (local, S3) y enrutar diferentes campos de archivo a diferentes backends usando storageId.

PaqueteRolUsado por
@rebasepro/typesInterfaces de TypeScript para colecciones, propiedades, entidades, pluginsTodo
@rebasepro/server-coreInicialización del servidor backend, API REST, autenticación, almacenamiento, WebSocketBackend
@rebasepro/clientSDK del cliente — Transporte HTTP, WebSocket, autenticaciónFrontend
@rebasepro/coreFramework React — Scaffold, controladores, formularios, rutas, hooksFrontend
@rebasepro/uiLibrería de componentes de UI autónoma (Tailwind v4 + Radix)Frontend
@rebasepro/authVistas de inicio de sesión, hooks del controlador de autenticación, gestión de usuariosFrontend
@rebasepro/studioEditor de colecciones, consola SQL, consola JS, editor RLS, navegador de almacenamientoFrontend
@rebasepro/cliCLI para generación de esquemas, migraciones de DB, generación de SDKHerramientas de desarrollo
@rebasepro/formexGestión ligera del estado de formularios de ReactFrontend
@rebasepro/data_enhancementPlugin de autocompletado de campos impulsado por IAFrontend
@rebasepro/data_import_exportImportación y exportación de CSV/JSON/ExcelFrontend
@rebasepro/schema_inferenceDetección automática de esquemas a partir de datos de base de datos existentesBackend/CLI
  1. El usuario abre una colección en la interfaz de administración
  2. El SDK del cliente envía GET /api/data/:slug + abre una suscripción WebSocket
  3. El backend consulta PostgreSQL a través de Drizzle ORM
  4. El transformador de datos deserializa los registros de la base de datos al formato de entidad
  5. La respuesta se envía al frontend, los componentes se renderizan
  6. WebSocket mantiene la vista sincronizada en tiempo real
  1. El usuario edita una entidad en el formulario
  2. Se ejecutan las callbacks beforeSave (validación, transformación)
  3. El SDK del cliente envía PUT /api/data/:slug/:id
  4. El backend serializa los valores, ejecuta UPDATE de Drizzle
  5. Se ejecutan las callbacks afterSave (efectos secundarios)
  6. La transmisión NOTIFY activa la actualización de WebSocket a todos los clientes
  7. Si el historial está habilitado, se registra una instantánea