De Rust-kern van Aurabase: een uniforme Backend-as-a-Service

De meeste open source Postgres BaaS verpakt hun services in meerdere talen. Dit is geen waardeoordeel – het is een architectonisch feit dat concrete gevolgen heeft: er moeten evenveel compilatieketens, foutconventies en auth-logica's synchroon blijven als er talen in het spel zijn.

Bij Aurabase is de productlaag die we zelf schrijven en onderhouden – gateway, auth, database, real-time, opslag, meldingen, AI, provisioning, accountbeheer – één Cargo-werkruimte, één taal, één enkele bouwketen. Dit is de keuze die dit dossier documenteert.

De root Cargo.toml declareert een Cargo-werkruimte in solver v2 met 18 leden: 11 zakelijke services, de aura-cliCLI, 5 gedeelde bibliotheken en de aurabase-rsSDK. Hier is de daadwerkelijke lijst, zoals deze in de repository verschijnt.

[workspace]
resolver = "2"

members = [
    # Diensten (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",
    # Gereedschap
    "aura-cli",
    # Libs (5)
    "libs/aura-core", "libs/aura-crypto", "libs/aura-db-adapters",
    "libs/aura-migrations", "libs/aura-telemetry",
    "aurabase-rs",
]

Gedeelde afhankelijkheden leven in [workspace.dependencies]: Axum 0.8 (met WebSockets, multipart, macro's), Tokio, Tower/Tower-HTTP, SQLx 0.8 (Postgres + MongoDB via mongodb voor secundaire NoSQL-engine), async-nats 0.47, sqlparser 0.53 (SQL-validatie van NL2SQL), oauth2 5, jsonwebtoken 10, en twee prestatiebibliotheken die in bijna elke service te vinden zijn: mimalloc als globale allocator en moka/dashmap voor de cache in het geheugen.

Het releaseprofiel documenteert een veronderstelde keuze: panic = "unwind" in plaats van "abort". De bestandsopmerking spreekt voor zich: een paniek in een Axum/Tokio-handler wordt geïsoleerd door de runtime (het betrokken verzoek retourneert 500) in plaats van het hele proces stil te leggen en concurrerende verzoeken af ​​te sluiten. Volgens dezelfde opmerking is de prestatiewinst vanabort (ongeveer 1 tot 2% van de RPS) het verlies aan isolatie niet waard. Dit is een afweging tussen betrouwbaarheid en snelheid die in de code wordt gedocumenteerd, en geen marketingclaim.

Een enkele cargo build --workspace compileert het geheel. Eén enkele cargo test --workspace voert de volledige testsuite uit. Eén enkele cargo clippy --workspace --all-targets -- -D warnings zorgt ervoor dat het hele product aan dezelfde regels voldoet. De details van deze structuur - overerving van afhankelijkheden, interne grafiek tussen libs en services, valkuilen die we tegenkwamen tijdens het groeien ervan - zijn het onderwerp van een speciaal artikel: Cargo-werkruimtearchitectuur, hoe je een Rust-backend met meerdere services structureert.

Roestlijnen per service (vind services -name '*.rs' | xargs wc -l, 23 augustus 2026):

aura-controle

36 024

aura-db

30 255

aura-auth

28 431

aura-voorziening

28 271

aura-meldingen

18 498

zal hebben

18 305

aura-poort

16 938

aura-realtime

16 799

aura-opslag

13 747

aura-functies

11 619

aura-migrator

538

Exclusief gedeelde libs (aura-db-adapters: 24.725 lijnen, aura-core: 7.259, aura-migraties: 3.641, aura-crypto: 2.718, aura-telemetrie: 201), de CLI (aura-cli: 9.845) en de Rust SDK (aurabase-rs: 6.363). aura-migrator, een migratietaak voor eenmalig gebruik en geen HTTP-server met een lange levensduur, blijft bewust de kleinste service op de werkplek.

Elke service is een onafhankelijk binair Axum/Tokio-bestand, met zijn eigen configuratie en poort. Tien van de elf stellen /health en /metrics bloot en declareren mimalloc als de globale allocator. De enige uitzondering, aura-migrator, is een taak voor één doel en niet een continu draaiende server.

De aura CLI (≈ 9.800 regels) communiceert met dezelfde API's als de SDK's en heeft geen bevoorrecht pad. De volledige referentie voor elke service staat in de architectuurdocumentatie en de CLI-referentie.

In een meertalige stapel moet een beveiligingsregel (foutformaat, SSRF-bescherming, snelheidsbeperking) in elke taal opnieuw worden geïmplementeerd, en deze regel verandert bijna altijd in de loop van de maanden. Aurabase codeert het één keer, in een werkruimtelib, die door alle betrokken services wordt gebruikt.

Direct gevolg: een beveiligingspatch in aura-core (SSRF-bescherming bijvoorbeeld) verspreidt zich naar elke consumentenservice in de volgende cargo build, en niet via vijf afzonderlijke patches in vijf talen.

aura-gateway scheidt twee oppervlakken die niet dezelfde clients of hetzelfde verificatiemodel hebben. Het datavlak (poort 8080, variabele GATEWAY_PORT) ontvangt SDK/app-verkeer, geverifieerd door een API-sleutel (apikey, X-API-Key of ?apikey=). Het beheervlak (poort 8090, MANAGEMENT_PORT) ontvangt Studio/admin-verkeer, geverifieerd door een JWT-console (Authorization: Bearer).

// Gegevensvlak: API-sleutel
.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))

// Beheerplan — JWT-console
.route("/v1/control/{*path}", any(control_proxy))

Elk vlak heeft zijn eigen stapel middleware – query-identificatie, toegangslogboek, snelheidslimiet, authenticatie (vlakspecifiek), stroomonderbreker en vervolgens proxy – geïmplementeerd in afzonderlijke modules (middleware/rate_limit.rs, middleware/circuit_breaker.rs, middleware/auth_data_plane.rs, middleware/auth_management_plane.rs) in plaats van een enkele keten die per ongeluk wordt gedeeld tussen twee oppervlakken die elkaar niet op dezelfde manier mogen vertrouwen. manier.

De exacte volgorde van de middlewares, de snelheidsbeperking per doel en de NATS/HTTP-proxy zijn het onderwerp van een speciaal artikel: dual-plane gateway, ontwerp een data-plane/management-plane API-gateway in Rust.

De zelf gegenereerde REST API die de SDK gebruikt, is geen interne Rust-module: het is de echte upstream binaire PostgREST (postgrest/postgrest:v12.2.8), geïmplementeerd in 2 replica's per speciaal project (deploy/cnpg/tenant-postgrest.yaml), op dezelfde locatie als de CNPG-instantie van de tenant. aura-provisioner maakt deze implementatie en aura-db onderzoekt het eindpunt OPTIONS na elke herlaadbeurt van het schema om te bevestigen dat PostgREST rekening heeft gehouden met de DDL-wijziging.

Dit is een veronderstelde architecturale keuze, geen sluiproute: PostgREST is een volwassen, algemeen aanvaard project, waarvan het gedrag beetje bij beetje herschrijven in Rust niets zou opleveren. Het Rust-werk van Aurabase concentreert zich op multi-tenant routing, provisioning, netwerkisolatie door NetworkPolicy, gedeelde authenticatie met de gateway, georkestreerd herladen van schema's - en niet binnen de query-engine zelf. Wat deze compatibiliteit werkelijk omvat, en waar het stopt, is het onderwerp van een apart artikel: PostgREST, daadwerkelijke compatibiliteit enalternatieven.

Dezelfde logica aan de GraphQL-kant: de Postgres-extensie pg_graphql (vooraf gecompileerd .deb-pakket, v1.6.1) wordt geïnstalleerd in de speciale CNPG-image en op aanvraag per project geactiveerd via het POST /v1/control/projects/{project_id}/graphql/enable-eindpunt - ook geen herschreven GraphQL-engine. Details en eerlijke vergelijking met Hasura en PostGraphile: Native GraphQL API op Postgres met pg_graphql.

Isolatie van meerdere tenants is niet afhankelijk van een WHERE tenant_id = ?-filter dat is toegevoegd door een applicatie-ORM: elk verzoek gaat door de rol aura_authenticator, die een SET LOCAL ROLE tenant_<uuid>-transactiescope uitvoert voordat het verzoek wordt uitgevoerd - precies het model dat PostgREST zelf verwacht. Row-Level Security doet de rest, op motorniveau, niet op bedrijfscodeniveau.

Niet alle projecten delen dezelfde Postgres-topologie. De aura-provisioner-code onthult een ProjectInstanceKind-type met ten minste twee echte varianten: FullyDedicated (CNPG-instantie volledig toegewijd aan het project) en SharedClusterDedicated (schema geïsoleerd door RLS op een gedeeld CNPG-cluster). Het onderschreven plan bepaalt de topologie – het is geen uniforme belofte van een “specifieke basis voor iedereen”.

Tien van de elf zakelijke services verklaren async-nats als een directe afhankelijkheid in hun Cargo.toml – alleen aura-migrator doet het zonder. Wat deze kratnaam niet zegt: deze services gebruiken bijna overal decore pub/sub API van NATS (Client::publish / publish_with_headers, maximaal één keer leveren zonder persistentie of herhaling), niet JetStream. Dit is het geval, geverifieerd in de code voor de drie toepassingen die er het meest toe doen: de distributie van de PostgreSQL CDC naar aura-realtime, de melding van Edge Functions-taken in aura-functions (de DLQ zelf bevindt zich in Postgres, niet in NATS) en inrichtingsgebeurtenissen tussen aura-provisioner en de rest van de vloot.

JetStream – de persistentie- en benoemde streams-modus van NATS – verschijnt slechts op één geverifieerde locatie in de monorepo: de cross-instance-aanwezigheid KV Store in aura-realtime (bucket aura_presence, geheugenopslag, 60 seconden max_age), die synchroniseert wie met welk kanaal is verbonden over meerdere instances van ws-front – een gedeelde status tussen instances, niet een stroom van gebeurtenissen om opnieuw af te spelen. Er zijn elders in de werkruimte geen persistente JetStream-streams gevonden. De details van de CDC-pijplijn - wal2json, verkiezing van een unieke cdc-worker door Lease Kubernetes, kern-NATS-fan-out naar de ws-front-replica's, RLS-herverificatie door abonnee - zijn het onderwerp van een speciaal artikel: zendt de PostgreSQL CDC uit met NATS. De Realtime-documentatie behandelt het gebruik aan de SDK-kant.

Dit is de belangrijkste nuance van dit bestand en de enige echte afwijking van pure Rust in de Aurabase-productcode. Elke functie heeft een veld runtime dat de waarde "wasm" of "deno"heeft. De aanroephandler kiest dienovereenkomstig het uitvoeringspad: feitelijk fragment, becommentarieerd in de code zelf:

// Verzending op basis van runtime: WASM (wasmtime) of Deno (V8 isoleert via edge-runtime)
let resp = if func.runtime == "wasm" {
    state.runtime.invoke(&wasm_bytes, &func.code_hash, req).await?
} else {
    // Proxy voor aura-edge-runtime — V8 isolaten (supabase/edge-runtime, MIT)
    proxy_to_edge_runtime(&state.config.edge_runtime_url, …).await?
};

De wasm-modus is native: aura-functions is rechtstreeks afhankelijk van Wasmtime (versie 43, bevat async en cranelift) en voert de module uit in hetzelfde Rust-proces, met brandstoftelling, onderbreking door tijdperk en geheugenbegrenzing via StoreLimits. De deno-modus – degene die standaard wordt gebruikt in de Studio-editor, voor vrijwel directe Deno.serve()-compatibiliteit met bestaande Supabase-code – delegeert de uitvoering aan aura-edge-runtime, een aparte TypeScript-service van ongeveer 550 regels, expliciet gemodelleerd – de bronbestandkopcommentaar citeert dit zelf – op supabase/edge-runtime (MIT-licentie), die elke aanroep isoleert in zijn eigen V8-isolaat.

Zie Edge Functionsvoor het instructiedocument van beide implementatiepaden. Voor het Deno-migratieplaybook van Supabase, zie Een Supabase-project migreren naar Aurabase, waarin dit onderscheid al vóór dit bestand werd gedocumenteerd.

Als je de API gewoon via een SDK aanroept, is deze architectuur onzichtbaar – dat is het doel. Het is vooral van belang voor drie doelgroepen: degenen die de operationele betrouwbaarheid van een multi-tenant backend evalueren voordat ze productiegegevens ernaar migreren, degenen die van plan zijn bij te dragen aan de repository (MIT, single monorepo), en degenen die willen begrijpen waarom een ​​beveiligingspatch aan de Aurabase-kant zich snel verspreidt in plaats van langzaam.

Concreet: een enkele IC (cargo build --workspace, cargo test --workspace, cargo clippy --workspace --all-targets -- -D warnings) bedekt 90% of meer van het productoppervlak. Een codebeoordeling op aura-core heeft mogelijk gevolgen voor tien services tegelijk: ten goede (een oplossing gaat onderweg niet verloren) en ten kwade (een slecht geïsoleerde wijziging verspreidt zich net zo snel). Het is een compromis, geen magische oplossing – en dat is precies de reden waarom we de daadwerkelijke architectuur documenteren in plaats van een marketingsamenvatting.

Deze pijlerpagina linkt naar de technische analyses van het cluster, zoals deze worden gepubliceerd. Actuele status op het moment van publicatie van deze pagina – links worden actief zodra het betreffende artikel online staat.

Cluster A — Kader en architectuur

Axum versus Actix-web: welk raamwerk voor een Rust-backend in productie?Gepubliceerd

Architectuur van de vrachtwerkruimte: hoe u een Rust-backend met meerdere services structureertGepubliceerd

Dual-plane gateway: een API-gateway op datavlak/beheervlak ontwerpen in RustGepubliceerd

Cluster B: zelf gegenereerde API op Postgres

PostgREST: wat compatibiliteit werkelijk inhoudt en welke alternatieven er zijnGepubliceerd

Native GraphQL API op Postgres met pg_graphql: wat Hasura en PostGraphile niet hetzelfde doenGepubliceerd

RLS en dedicated basis per project: de keuze voor multi-tenant isolatie van AurabaseGepubliceerd

Cluster C — Realtime en berichtenuitwisseling

PostgreSQL CDC distribueren met NATS: real-time architectuurGepubliceerd

Cluster D — Edge Functions WebAssembly

Cluster E — Migratie en alternatieven

Migreer een Supabase-project naar Aurabase zonder uw RLS-beleid te herschrijvenGepubliceerd

Soevereine zelfhosting: Aurabase positioneren tegen Rust-native BaaS Binnenkort beschikbaar