Der Rust-Kern von Aurabase: ein einheitliches Backend-as-a-Service

Die meisten Open-Source-Postgres-BaaS-Pakete bieten ihre Dienste in mehreren Sprachen an. Dies ist kein Werturteil – es ist eine architektonische Tatsache, die konkrete Konsequenzen hat: Es müssen so viele Kompilierungsketten, Fehlerkonventionen und Authentifizierungslogiken synchron gehalten werden, wie Sprachen im Spiel sind.

Bei Aurabase ist die Produktschicht, die wir selbst schreiben und pflegen – Gateway, Authentifizierung, Datenbank, Echtzeit, Speicher, Benachrichtigungen, KI, Bereitstellung, Kontoverwaltung – ein einziger Cargo-Arbeitsbereich, eine einzige Sprache, eine einzige Build-Kette. Dies ist die Wahl, die diese Datei dokumentiert.

Der Stamm Cargo.toml deklariert einen Cargo-Arbeitsbereich in Resolver v2 mit 18 Mitgliedern: 11 Geschäftsdienste, die aura-cliCLI, 5 gemeinsam genutzte Bibliotheken und das aurabase-rsSDK. Hier ist die tatsächliche Liste, wie sie im Repository erscheint.

[workspace]
resolver = "2"

members = [
    # Dienstleistungen (11)
    "services/aura-gateway", "services/aura-auth", "services/aura-db",
    "services/aura-provisioner", "services/aura-realtime", "services/aura-storage",
    "services/aura-functions", "services/aura-notifications", "services/aura-ai",
    "services/aura-migrator", "services/aura-control",
    # Werkzeuge
    "aura-cli",
    # Bibliotheken (5)
    "libs/aura-core", "libs/aura-crypto", "libs/aura-db-adapters",
    "libs/aura-migrations", "libs/aura-telemetry",
    "aurabase-rs",
]

Gemeinsame Abhängigkeiten leben in [workspace.dependencies]: Axum 0.8 (mit WebSockets, Multipart, Makros), Tokio, Tower/Tower-HTTP, SQLx 0.8 (Postgres + MongoDB über mongodb für sekundäre NoSQL-Engine), async-nats 0.47, sqlparser 0.53 (SQL-Validierung von NL2SQL), oauth2 5, jsonwebtoken 10 und zwei Leistungsbibliotheken, die in fast jedem Dienst zu finden sind: mimalloc als globaler Allokator und moka/dashmap für den In-Memory-Cache.

Das Release-Profil dokumentiert eine angenommene Wahl: panic = "unwind" statt "abort". Der Dateikommentar ist selbsterklärend – eine Panik in einem Axum/Tokio-Handler wird von der Laufzeit isoliert (die betroffene Anfrage gibt 500 zurück), anstatt den gesamten Prozess zum Absturz zu bringen und konkurrierende Anfragen abzuschneiden. Der Leistungsgewinn vonabort (ungefähr 1 bis 2 % von RPS) ist laut derselben Anmerkung den Verlust der Isolierung nicht wert. Hierbei handelt es sich um einen im Code dokumentierten Kompromiss zwischen Zuverlässigkeit und Geschwindigkeit, nicht um eine Marketingaussage.

Ein einziger cargo build --workspace kompiliert das Ganze. Ein einzelner cargo test --workspace führt die gesamte Testsuite aus. Ein einziger cargo clippy --workspace --all-targets -- -D warnings regelt das gesamte Produkt nach denselben Regeln. Die Details dieser Struktur – Vererbung von Abhängigkeiten, interner Graph zwischen Bibliotheken und Diensten, Fallstricke, auf die wir beim Erweitern gestoßen sind – sind Gegenstand eines speziellen Artikels: Cargo-Workspace-Architektur, wie man ein Rust-Backend mit mehreren Diensten strukturiert.

Rust-Zeilen nach Dienst (find services -name '*.rs' | xargs wc -l, 23. August 2026):

Aura-Kontrolle

36 024

Aura-db

30 255

Aura-Auth

28 431

Aura-Versorger

28 271

Aura-Benachrichtigungen

18 498

wird haben

18 305

Aura-Gateway

16 938

Aura-Echtzeit

16 799

Aura-Speicher

13 747

Aura-Funktionen

11 619

Aura-Migrator

538

Ausgenommen gemeinsam genutzte Bibliotheken (aura-db-adapters: 24.725 Zeilen, aura-core: 7.259, aura-migrations: 3.641, aura-crypto: 2.718, aura-telemetry: 201), die CLI (aura-cli: 9.845) und das Rust SDK (aurabase-rs: 6.363). aura-migrator, ein einmaliger Migrationsjob und kein langlebiger HTTP-Server, bleibt bewusst der kleinste Dienst im Arbeitsbereich.

Jeder Dienst ist eine unabhängige Axum/Tokio-Binärdatei mit eigener Konfiguration und eigenem Port. Zehn der elf stellen /health und /metrics bereit und deklarieren mimalloc als globalen Allokator – die einzige Ausnahme, aura-migrator, ist ein Einzweckjob und kein kontinuierlich laufender Server.

Die aura CLI (≈ 9.800 Zeilen) kommuniziert mit denselben APIs wie die SDKs – sie hat keinen privilegierten Pfad. Die vollständige Referenz für jeden Dienst befindet sich in der Architekturdokumentation und in der CLI-Referenz .

In einem polyglotten Stapel muss eine Sicherheitsregel – Fehlerformat, SSRF-Schutz, Ratenbegrenzung – in jeder Sprache neu implementiert werden und schwankt fast immer im Laufe der Monate. Aurabase codiert es einmal in einer Arbeitsbereichsbibliothek, die von allen betroffenen Diensten genutzt wird.

Direkte Konsequenz: Ein Sicherheitspatch in aura-core – zum Beispiel SSRF-Schutz – wird im nächsten cargo buildan jeden Verbraucherdienst weitergegeben, nicht über fünf separate Patches in fünf Sprachen.

aura-gateway trennt zwei Oberflächen, die weder dieselben Clients noch dasselbe Authentifizierungsmodell haben. Die Datenebene (Port 8080, Variable GATEWAY_PORT) empfängt SDK-/App-Verkehr, authentifiziert durch API-Schlüssel (apikey, X-API-Key oder ?apikey=). Die Verwaltungsebene (Port 8090, MANAGEMENT_PORT) empfängt Studio-/Administratordatenverkehr, der von einer JWT-Konsole (Authorization: Bearer) authentifiziert wird.

// Datenebene – API-Schlüssel
.route("/v1/auth/{*path}", any(auth_proxy))
.route("/v1/db/{*path}", any(db_proxy))
.route("/v1/realtime/ws", get(realtime_ws_proxy))
.route("/v1/realtime/sse", get(realtime_sse_proxy))
.route("/v1/storage/{*path}", any(storage_proxy))
.route("/v1/notifications/{*path}", any(notifications_proxy))
.route("/v1/ai/{*path}", any(ai_dispatcher))
.route("/v1/functions/{*path}", any(functions_proxy))

// Managementplan – JWT-Konsole
.route("/v1/control/{*path}", any(control_proxy))

Jede Ebene verfügt über einen eigenen Middleware-Stapel – Abfrageidentifikation, Zugriffsprotokoll, Ratenbegrenzung, Authentifizierung (ebenenspezifisch), Leistungsschalter, dann Proxy – implementiert in separaten Modulen (middleware/rate_limit.rs, middleware/circuit_breaker.rs, middleware/auth_data_plane.rs, middleware/auth_management_plane.rs) und nicht in einer einzelnen Kette, die versehentlich von zwei Oberflächen gemeinsam genutzt wird, die einander nicht auf die gleiche Weise vertrauen sollten. Weg.

Die genaue Reihenfolge der Middlewares, die Ratenbegrenzung pro Ziel und der NATS/HTTP-Proxy sind Gegenstand eines speziellen Artikels: Dual-Plane Gateway, Design a Data-Plane/Management-Plane API Gateway in Rust.

Die selbst generierte REST-API, die das SDK nutzt, ist kein internes Rust-Modul: Es handelt sich um die echte Upstream-Binärdatei PostgREST (postgrest/postgrest:v12.2.8), die in 2 Replikaten pro dediziertem Projekt (deploy/cnpg/tenant-postgrest.yaml) bereitgestellt wird und sich zusammen mit der CNPG-Instanz des Mandanten befindet. aura-provisioner erstellt diese Bereitstellung und aura-db prüft seinen Endpunkt OPTIONS nach jedem Neuladen des Schemas, um zu bestätigen, dass PostgREST die DDL-Änderung berücksichtigt hat.

Dies ist eine angenommene architektonische Entscheidung, keine Abkürzung: PostgREST ist ein ausgereiftes, weit verbreitetes Projekt, dessen schrittweises Umschreiben des Verhaltens in Rust nichts bringen würde. Die Rust-Arbeit von Aurabase konzentriert sich auf – mandantenfähiges Routing, Bereitstellung, Netzwerkisolation durch NetworkPolicy, gemeinsame Authentifizierung mit dem Gateway, orchestriertes Schema-Neuladen – und nicht auf die Abfrage-Engine selbst. Was diese Kompatibilität wirklich abdeckt und wo sie aufhört, ist Gegenstand eines separaten Artikels: PostgREST, tatsächliche Kompatibilität undAlternativen.

Dieselbe Logik auf der GraphQL-Seite: Die Postgres-Erweiterung pg_graphql (vorkompiliertes .deb-Paket, v1.6.1) wird im dedizierten CNPG-Image installiert und bei Bedarf pro Projekt über den POST /v1/control/projects/{project_id}/graphql/enable-Endpunkt aktiviert – auch keine neu geschriebene GraphQL-Engine. Details und ehrlicher Vergleich mit Hasura und PostGraphile: Native GraphQL API auf Postgres mit pg_graphql.

Die mandantenfähige Isolation basiert nicht auf einem WHERE tenant_id = ?-Filter, der von einem Anwendungs-ORM hinzugefügt wird: Jede Anfrage durchläuft die Rolle aura_authenticator, die vor der Ausführung der Anfrage eine SET LOCAL ROLE tenant_<uuid>-Transaktionsebene ausführt – genau das Modell, das PostgREST selbst erwartet. Den Rest erledigt Row-Level Security auf Engine-Ebene, nicht auf Geschäftscode-Ebene.

Nicht alle Projekte verwenden dieselbe Postgres-Topologie. Der aura-provisioner-Code stellt einen ProjectInstanceKind-Typ mit mindestens zwei realen Varianten bereit: FullyDedicated (CNPG-Instanz, die vollständig dem Projekt gewidmet ist) und SharedClusterDedicated (durch RLS isoliertes Schema auf einem gemeinsam genutzten CNPG-Cluster). Der abonnierte Plan bestimmt die Topologie – es handelt sich nicht um ein einheitliches Versprechen einer „dedizierten Basis für alle“.

Zehn der elf Business Services deklarieren async-nats als direkte Abhängigkeit in ihrem Cargo.toml – nur aura-migrator verzichtet darauf. Was dieser Crate-Name nicht sagt: Diese Dienste verwenden fast überall die-Kern-Pub/Sub-API (Client::publish / publish_with_headers, at-most-once-Zustellung ohne Persistenz oder Wiedergabe), nicht JetStream. Dies ist im Code für die drei wichtigsten Verwendungszwecke bestätigt: die Verteilung des PostgreSQL-CDC an aura-realtime, die Benachrichtigung über Edge Functions-Jobs in aura-functions (der DLQ selbst befindet sich in Postgres, nicht in NATS) und Bereitstellungsereignisse zwischen aura-provisioner und dem Rest der Flotte.

JetStream – der Persistenz- und Named-Streams-Modus von NATS – erscheint nur an einer verifizierten Stelle im Monorepo: dem instanzübergreifenden Präsenz-KV-Speicher in aura-realtime (Bucket aura_presence, Speicherspeicher, 60 Sekunden max_age), der synchronisiert, wer über mehrere Instanzen von ws-front mit welchem Kanal verbunden ist – ein instanzübergreifender gemeinsamer Zustand, kein Strom von wiederzugebenden Ereignissen. An anderer Stelle im Arbeitsbereich wurden keine persistenten JetStream-Streams gefunden. Die Details der CDC-Pipeline – wal2json, Wahl eines eindeutigen cdc-worker durch Lease Kubernetes, Kern-NATS-Fanout zu den ws-front-Replikaten, RLS-Neuverifizierung durch den Abonnenten – sind Gegenstand eines speziellen Artikels: sendete den PostgreSQL CDC mit NATS. Die Echtzeitdokumentation behandelt die Verwendung auf der SDK-Seite.

Dies ist die wichtigste Nuance dieser Datei und die einzige wirkliche Abweichung vom reinen Rust im Aurabase-Produktcode. Jede Funktion trägt ein runtime-Feld, das den Wert "wasm" oder "deno"hat. Der Aufrufhandler wählt den Ausführungspfad entsprechend aus – tatsächlicher Ausschnitt, auskommentiert im Code selbst:

// Versand nach Laufzeit: WASM (wasmtime) oder Deno (V8 isoliert über Edge-Runtime)
let resp = if func.runtime == "wasm" {
    state.runtime.invoke(&wasm_bytes, &func.code_hash, req).await?
} else {
    // Proxy für Aura-Edge-Runtime – V8-Isolate (supabase/edge-runtime, MIT)
    proxy_to_edge_runtime(&state.config.edge_runtime_url, …).await?
};

Der wasm-Modus ist nativ: aura-functions hängt direkt von Wasmtime (Version 43, Funktionen async und cranelift) ab und führt das Modul im gleichen Rust-Prozess aus, mit Treibstoffzählung, Unterbrechung nach Epoche und Speicherbegrenzung über StoreLimits. Der deno-Modus – der standardmäßig im Studio-Editor verwendet wird, um nahezu direkte Deno.serve()-Kompatibilität mit vorhandenem Supabase-Code zu gewährleisten – delegiert die Ausführung an aura-edge-runtime, einen separaten TypeScript-Dienst mit etwa 550 Zeilen, der explizit modelliert ist – der Quelldatei-Header-Kommentar selbst zitiert ihn – auf supabase/edge-runtime (MIT Lizenz), die jeden Aufruf in sein eigenes V8-Isolat isoliert.

Die Anleitungen zu beiden Bereitstellungspfaden finden Sie unter Edge Functions. Das Deno-Migrations-Playbook von Supabase finden Sie unter Migrate a Supabase project to Aurabase, wo dieser Unterschied bereits vor dieser Datei dokumentiert wurde.

Wenn Sie die API einfach über ein SDK aufrufen, ist diese Architektur unsichtbar – das ist das Ziel. Es ist vor allem für drei Zielgruppen von Bedeutung: diejenigen, die die Betriebszuverlässigkeit eines Multi-Tenant-Backends bewerten, bevor sie Produktionsdaten dorthin migrieren, diejenigen, die einen Beitrag zum Repository leisten möchten (MIT, einzelnes Monorepo) und diejenigen, die verstehen möchten, warum sich ein Sicherheitspatch auf der Aurabase-Seite eher schnell als langsam verbreitet.

Konkret: Ein einzelner IC (cargo build --workspace, cargo test --workspace, cargo clippy --workspace --all-targets -- -D warnings) bedeckt 90 % oder mehr der Produktoberfläche. Eine Codeüberprüfung auf aura-core betrifft möglicherweise zehn Dienste gleichzeitig – zum Guten (ein Fix geht unterwegs nicht verloren) und zum Schlechten (eine schlecht isolierte Änderung verbreitet sich genauso schnell). Es handelt sich um einen Kompromiss, nicht um eine magische Lösung – und genau aus diesem Grund dokumentieren wir die tatsächliche Architektur und nicht eine Marketingzusammenfassung.

Diese Pillar-Seite enthält Links zu den technischen Analysen des Clusters, sobald diese veröffentlicht werden. Aktueller Stand zum Zeitpunkt der Veröffentlichung dieser Seite – Links werden aktiv, sobald der entsprechende Artikel online ist.

Cluster A – Framework und Architektur

Axum vs Actix-web: Welches Framework für ein Rust-Backend in der Produktion?Veröffentlicht

Cargo-Workspace-Architektur: So strukturieren Sie ein Rust-Backend mit mehreren DienstenVeröffentlicht

Dual-Plane-Gateway: Entwerfen eines Datenebenen-/Verwaltungsebenen-API-Gateways in RustVeröffentlicht

Cluster B – Selbstgenerierte API auf Postgres

PostgREST: Was die Kompatibilität wirklich abdeckt und welche Alternativen es gibtVeröffentlicht

Native GraphQL-API auf Postgres mit pg_graphql: Was Hasura und PostGraphile nicht dasselbe machenVeröffentlicht

RLS und dedizierte Basis pro Projekt: die Wahl der mandantenfähigen Isolierung von AurabaseVeröffentlicht

Cluster C – Echtzeit und Messaging

Verteilen Sie PostgreSQL CDC mit NATS: EchtzeitarchitekturVeröffentlicht

Cluster D – Edge Functions WebAssembly

Cluster E – Migration & Alternativen

Migrieren Sie ein Supabase-Projekt zu Aurabase, ohne Ihre RLS-Richtlinien neu zu schreiben.Veröffentlicht

Souveränes Selbsthosting: Positionierung von Aurabase gegenüber Rust-nativem BaaSIn Kürze erhältlich