Zum Inhalt springen

Backend-Übersicht

Das Rebase-Backend ist ein auf Hono basierender Node.js-Server, der Folgendes bietet:

  • REST-API — Automatisch generierte CRUD-Endpunkte für jede Sammlung
  • Authentifizierung — JWT-Token, Google OAuth, Benutzer-/Rollenverwaltung
  • Speicher — Datei-Upload/Download mit lokalem Dateisystem oder S3
  • WebSocket — Echtzeit-Datensynchronisation über PostgreSQL LISTEN/NOTIFY
  • Entitätshistorie — Audit-Trail für jede Datenänderung
  • Datenbank-Verzweigung — Sofortige, isolierte Datenbankkopien für Entwicklung/Staging/Tests
  • Cron-Jobs — Geplante Hintergrundaufgaben mit Überwachungs-Dashboard

Alles wird mit einer einzigen Funktion initialisiert:

import { initializeRebaseBackend } from "@rebasepro/server-core";
import { createPostgresAdapter } from "@rebasepro/server-postgresql";
import { env } from "./env";
const instance = await initializeRebaseBackend({
app,
server,
collectionsDir: "./config/collections",
database: createPostgresAdapter({
connection: db,
schema: { tables, enums, relations }
}),
auth: {
jwtSecret: env.JWT_SECRET,
},
storage: { type: "local", basePath: "./uploads" },
history: true,
enableSwagger: env.NODE_ENV !== "production"
});

Nach der Initialisierung werden diese Routen gemountet:

PfadZweck
/api/auth/*Authentifizierung (Registrierung, Anmeldung, Aktualisierung, Google OAuth)
/api/admin/*Benutzer- und Rollenverwaltung (nur für Administratoren)
/api/storage/*Datei-Upload, -Download und -Löschung
/api/data/collectionsEndpunkt für Sammlungsmetadaten
/api/data/:slugCRUD-Operationen pro Sammlung (GET, POST, PUT, DELETE)
/api/data/:slug/:id/historyEntitätsänderungshistorie (falls aktiviert)
/api/data/docsOpenAPI-Spezifikation (wenn enableSwagger: true)
/api/data/swaggerSwagger UI (Entwicklungsmodus, wenn enableSwagger: true)
/api/functions/*Benutzerdefinierte Funktionsrouten (wenn functionsDir gesetzt ist)
/api/cron/*Cron-Job-Verwaltung (nur für Administratoren, wenn cronsDir gesetzt ist)
WebSocket bei UpgradeEchtzeit-Abonnements
interface RebaseBackendConfig {
// HTTP framework
app: Hono; // Hono application instance
server: Server; // Node.js HTTP server (for WebSocket attachment)
basePath?: string; // Route prefix (default: "/api")
// Collections
collections?: EntityCollection[]; // Your collection definitions
collectionsDir?: string; // Auto-load collections from a directory
// Bootstrappers (Databases, Auth, Realtime, etc.)
bootstrappers: BackendBootstrapper[];
// Authentication
auth?: AuthConfig;
// File storage
storage?: BackendStorageConfig | Record<string, BackendStorageConfig>;
// Entity history
history?: boolean | HistoryConfig;
// OpenAPI/Swagger
enableSwagger?: boolean;
// Custom API endpoints
functionsDir?: string; // Auto-load Hono routes from a directory
// Scheduled tasks
cronsDir?: string; // Auto-load cron jobs from a directory
// Logging
logging?: { level?: "error" | "warn" | "info" | "debug" };
}

initializeRebaseBackend gibt eine RebaseBackendInstance mit Zugriff auf interne Dienste zurück:

const instance = await initializeRebaseBackend(config);
// Internal service access
instance.driver // Default data driver
instance.driverRegistry // All drivers (for multi-database)
instance.realtimeService // Default realtime service
instance.userService // User management
instance.roleService // Role management
instance.storageController // Default storage
instance.storageRegistry // All storage backends
instance.collectionRegistry // Collection metadata
instance.historyService // Entity history
instance.cronScheduler // Cron job scheduler (when cronsDir is set)

Hinweis: Obwohl die instance diese internen Dienste offenlegt, sollte Anwendungscode (wie benutzerdefinierte Funktionen und Cron-Jobs) das globale rebase-Singleton von @rebasepro/server-core verwenden, um mit der Backend-API zu interagieren.

Die REST-API wird automatisch aus Ihren Sammlungen generiert. Jede Sammlung erhält diese Endpunkte:

MethodePfadBeschreibung
GET/api/data/:slugEntitäten auflisten (mit Filter, Sortierung, Limit, Suche)
GET/api/data/:slug/:idEine einzelne Entität abrufen
POST/api/data/:slugEine neue Entität erstellen
PUT/api/data/:slug/:idEine Entität aktualisieren
DELETE/api/data/:slug/:idEine Entität löschen
ParameterBeschreibungBeispiel
filterJSON-kodierte Filterbedingungen?filter={"active":["==",true]}
orderBySortierfeld?orderBy=created_at
orderSortierrichtung?order=desc
limitSeitengröße?limit=25
startAfterCursor für die Paginierung?startAfter=encodedCursor
searchVolltextsuche?search=laptop

Der WebSocket-Server bindet sich an denselben HTTP-Server und bietet Echtzeit-Abonnements:

  • Abonnieren Sie Sammlungsänderungen — werden Sie benachrichtigt, wenn eine Entität in einer Sammlung erstellt, aktualisiert oder gelöscht wird
  • Abonnieren Sie Entitätsänderungen — werden Sie benachrichtigt, wenn sich eine bestimmte Entität ändert
  • Automatische Wiederverbindungs-Behandlung im Client-SDK

Das Backend verwendet intern PostgreSQL LISTEN/NOTIFY. Für Multi-Instanz-Bereitstellungen geben Sie einen connectionString in Ihrem PostgresBootstrapper an, um die Instanz-übergreifende Übertragung zu ermöglichen.

Das Backend enthält einen Fehler-Handler, der alle Ausnahmen abfängt und strukturierte Fehlerantworten zurückgibt:

{
"error": {
"message": "Entity not found",
"code": "not-found",
"status": 404
}
}

Schlägt die Initialisierung fehl (z. B. Datenbankverbindungsfehler), startet der Server trotzdem, gibt aber für alle API-Anfragen 503 zurück, mit einer beschreibenden Fehlermeldung in den Logs.