Núcleo Rust de Aurabase: um backend como serviço unificado

A maioria dos Postgres BaaS de código aberto empacota seus serviços em vários idiomas. Este não é um julgamento de valor — é um fato arquitetônico que tem consequências concretas: tantas cadeias de compilação, convenções de erro e lógicas de autenticação para manter sincronizadas quantas forem as linguagens em jogo.

Na Aurabase, a camada de produto que escrevemos e mantemos - gateway, autenticação, banco de dados, tempo real, armazenamento, notificações, IA, provisionamento, gerenciamento de contas - é um único espaço de trabalho Cargo, um único idioma, uma única cadeia de construção. Esta é a escolha que este arquivo documenta.

A raiz Cargo.toml declara um espaço de trabalho Cargo no resolvedor v2 com 18 membros: 11 serviços de negócios, a CLI aura-cli, 5 bibliotecas compartilhadas e o SDK aurabase-rs. Aqui está a lista real, conforme aparece no repositório.

[workspace]
resolver = "2"

members = [
    # Serviços (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",
    # Ferramentas
    "aura-cli",
    # Bibliotecas (5)
    "libs/aura-core", "libs/aura-crypto", "libs/aura-db-adapters",
    "libs/aura-migrations", "libs/aura-telemetry",
    "aurabase-rs",
]

Dependências compartilhadas residem em [workspace.dependencies]: Axum 0.8 (com WebSockets, multipart, macros), Tokio, Tower/Tower-HTTP, SQLx 0.8 (Postgres + MongoDB via mongodb para mecanismo NoSQL secundário), async-nats 0,47, sqlparser 0,53 (validação SQL de NL2SQL), oauth2 5, jsonwebtoken 10 e duas bibliotecas de desempenho encontradas em quase todos os serviços: mimalloc como alocador global e moka/dashmap para o cache na memória.

O perfil de lançamento documenta uma escolha assumida: panic = "unwind" em vez de "abort". O comentário do arquivo é autoexplicativo – um pânico em um manipulador Axum/Tokio é isolado pelo tempo de execução (a solicitação afetada retorna 500) em vez de interromper todo o processo e cortar solicitações concorrentes. O ganho de desempenho deabort (aproximadamente 1 a 2% do RPS) não compensa a perda de isolamento, segundo esta mesma nota. Esta é uma compensação entre confiabilidade e velocidade documentada no código, não uma afirmação de marketing.

Um único cargo build --workspace compila tudo. Um único cargo test --workspace executa todo o conjunto de testes. Um único cargo clippy --workspace --all-targets -- -D warnings lint todo o produto com as mesmas regras. Os detalhes dessa estrutura - herança de dependências, gráfico interno entre libs e serviços, armadilhas que encontramos durante seu crescimento - são o assunto de um artigo dedicado: Arquitetura do espaço de trabalho de carga, como estruturar um backend Rust multisserviço.

Linhas de ferrugem por serviço (encontre services -name '*.rs' | xargs wc -l, 23 de agosto de 2026):

controle de aura

36 024

aura-db

30 255

aura-auth

28 431

provedor de aura

28 271

notificações de aura

18 498

terá

18 305

gateway da aura

16 938

aura em tempo real

16 799

armazenamento de aura

13 747

funções da aura

11 619

migrador de aura

538

Excluindo bibliotecas compartilhadas (adaptadores aura-db: 24.725 linhas, aura-core: 7.259, migrações de aura: 3.641, aura-crypto: 2.718, aura-telemetria: 201), o CLI (aura-cli: 9.845) e o Rust SDK (aurabase-rs: 6.363). O aura-migrator, um trabalho de migração de uso único e não um servidor HTTP de longa duração, continua deliberadamente sendo o menor serviço no espaço de trabalho.

Cada serviço é um binário Axum/Tokio independente, com configuração e porta próprias. Dez dos onze expõem /health e /metrics e declaram mimalloc como o alocador global — a única exceção, aura-migrator, é um trabalho de propósito único em vez de um servidor em execução contínua.

A CLI aura (≈ 9.800 linhas) se comunica com as mesmas APIs que os SDKs — não possui caminho privilegiado. A referência completa para cada serviço está na documentação da arquitetura e na referência CLI .

Em uma pilha poliglota, uma regra de segurança – formato de erro, proteção SSRF, limitação de taxa – deve ser reimplementada em cada idioma e quase sempre muda ao longo dos meses. Aurabase codifica-o uma vez, em uma biblioteca de espaço de trabalho, consumida por todos os serviços envolvidos.

Consequência direta: um patch de segurança em aura-core — proteção SSRF, por exemplo — se propaga para cada serviço de consumidor no próximo cargo build, e não por meio de cinco patches separados em cinco idiomas.

aura-gateway separa duas superfícies que não possuem os mesmos clientes nem o mesmo modelo de autenticação. O plano de dados (porta 8080, variável GATEWAY_PORT) recebe tráfego SDK/app, autenticado pela chave API (apikey, X-API-Key ou ?apikey=). O plano de gerenciamento (porta 8090, MANAGEMENT_PORT) recebe tráfego Studio/admin, autenticado por um console JWT (Authorization: Bearer).

// Plano de dados – chave API
.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))

// Plano de gerenciamento — console JWT
.route("/v1/control/{*path}", any(control_proxy))

Cada plano carrega sua própria pilha de middleware - identificação de consulta, log de acesso, limite de taxa, autenticação (específica do plano), disjuntor e proxy - implementado em módulos separados (middleware/rate_limit.rs, middleware/circuit_breaker.rs, middleware/auth_data_plane.rs, middleware/auth_management_plane.rs) em vez de uma única cadeia compartilhada acidentalmente entre duas superfícies que não deveriam confiar uma na outra da mesma maneira. caminho.

A ordem exata dos middlewares, o limite de taxa por alvo e o proxy NATS/HTTP são o assunto de um artigo dedicado: gateway de plano duplo, projete um gateway de API de plano de dados/plano de gerenciamento em Rust.

A API REST autogerada que o SDK consome não é um módulo Rust interno: é o binário upstream real PostgREST (postgrest/postgrest:v12.2.8), implantado em 2 réplicas por projeto dedicado (deploy/cnpg/tenant-postgrest.yaml), co-localizado com a instância CNPG do locatário. aura-provisioner cria esta implantação e aura-db investiga seu endpoint OPTIONS após cada recarga de esquema para confirmar se PostgREST levou em consideração a alteração DDL.

Esta é uma escolha arquitetônica assumida, não um atalho: PostgREST é um projeto maduro e amplamente adotado, cujo comportamento reescrito pouco a pouco em Rust não traria nada. O trabalho do Rust da Aurabase se concentra em - roteamento multilocatário, provisionamento, isolamento de rede por NetworkPolicy, autenticação compartilhada com o gateway, recarga de esquema orquestrada - e não dentro do próprio mecanismo de consulta. O que essa compatibilidade realmente cobre e onde ela termina é o assunto de um artigo separado: PostgREST, compatibilidade real e alternativas.

A mesma lógica no lado GraphQL: a extensão Postgres pg_graphql (pacote .deb pré-compilado, v1.6.1) é instalada na imagem CNPG dedicada e ativada sob demanda por projeto por meio do endpoint POST /v1/control/projects/{project_id}/graphql/enable - também não é um mecanismo GraphQL reescrito. Detalhes e comparação honesta com Hasura e PostGraphile: API GraphQL nativa no Postgres com pg_graphql.

O isolamento multilocatário não depende de um filtro WHERE tenant_id = ? adicionado por um ORM de aplicativo: cada solicitação passa pela função aura_authenticator, que executa uma transação SET LOCAL ROLE tenant_<uuid> com escopo definido antes de executar a solicitação - exatamente o modelo que o próprio PostgREST espera. A segurança em nível de linha faz o resto, no nível do mecanismo, não no nível do código comercial.

Nem todos os projetos compartilham a mesma topologia do Postgres. O código aura-provisioner expõe um tipo ProjectInstanceKind com pelo menos duas variantes reais: FullyDedicated (instância CNPG inteiramente dedicada ao projeto) e SharedClusterDedicated (esquema isolado por RLS em um cluster CNPG compartilhado). O plano assinado determina a topologia — não é uma promessa uniforme de uma “base dedicada para todos”.

Dez dos onze serviços empresariais declaram async-nats como uma dependência direta em seu Cargo.toml — apenas aura-migrator funciona sem ele. O que esse nome de caixa não diz: esses serviços em quase todos os lugares usam a API principal pub/sub do NATS (Client::publish / publish_with_headers, entrega no máximo uma vez sem persistência ou repetição), não JetStream. Este é o caso verificado no código para os três usos mais importantes: a distribuição do CDC do PostgreSQL para aura-realtime, a notificação de trabalhos de Edge Functions em aura-functions (o próprio DLQ reside em Postgres, não em NATS) e eventos de provisionamento entre aura-provisioner e o resto da frota.

JetStream - modo de persistência e fluxos nomeados do NATS - aparece apenas em um local verificado no monorepo: o KV Store de presença entre instâncias em aura-realtime (balde aura_presence, armazenamento de memória, max_agede 60 segundos ), que sincroniza quem está conectado a qual canal em várias instâncias de ws-front - um estado compartilhado entre instâncias, não um fluxo de eventos a serem reproduzidos. Nenhum fluxo JetStream persistente foi encontrado em outro lugar no espaço de trabalho. Os detalhes do pipeline do CDC - wal2json, eleição de um cdc-worker exclusivo por Lease Kubernetes, fan-out principal do NATS para as réplicas ws-front, nova verificação de RLS por assinante - são o assunto de um artigo dedicado: transmite o CDC do PostgreSQL com NATS. A documentação Realtime cobre o uso no lado do SDK.

Esta é a nuance mais importante deste arquivo e o único desvio real do Rust puro no código do produto Aurabase. Cada função carrega um campo runtime que vale "wasm" ou "deno". O manipulador de invocação escolhe o caminho de execução de acordo – trecho real, comentado no próprio código:

// Despache de acordo com o tempo de execução: WASM (wasmtime) ou Deno (V8 isola via edge-runtime)
let resp = if func.runtime == "wasm" {
    state.runtime.invoke(&wasm_bytes, &func.code_hash, req).await?
} else {
    // Proxy para aura-edge-runtime — Isolados V8 (supabase/edge-runtime, MIT)
    proxy_to_edge_runtime(&state.config.edge_runtime_url, …).await?
};

O modo wasm é nativo: aura-functions depende diretamente de Wasmtime (versão 43, apresenta async e cranelift) e executa o módulo no mesmo processo Rust, com contagem de combustível, interrupção por época e limite de memória via StoreLimits. O modo deno - aquele usado por padrão no editor Studio, para compatibilidade quase direta do Deno.serve() com o código Supabase existente - delega a execução para aura-edge-runtime, um serviço TypeScript separado de cerca de 550 linhas, modelado explicitamente - o próprio comentário do cabeçalho do arquivo de origem o cita - em supabase/edge-runtime (MIT licença), que isola cada invocação em seu próprio V8 Isolate.

Para obter o documento de instruções de ambos os caminhos de implantação, consulte Edge Functions. Para o manual de migração Deno do Supabase, consulte Migrar um projeto Supabase para Aurabase, que já documentou essa distinção antes deste arquivo.

Se você apenas chamar a API por meio de um SDK, essa arquitetura ficará invisível — esse é o objetivo. É importante principalmente para três públicos: aqueles que avaliam a confiabilidade operacional de um back-end multilocatário antes de migrar os dados de produção para ele, aqueles que planejam contribuir para o repositório (MIT, monorepo único) e aqueles que desejam entender por que um patch de segurança no lado do Aurabase se espalha rapidamente em vez de lentamente.

Concretamente: um único IC (cargo build --workspace, cargo test --workspace, cargo clippy --workspace --all-targets -- -D warnings) cobre 90% ou mais da superfície do produto. Uma revisão de código em aura-core afeta potencialmente dez serviços de uma vez — para melhor (uma correção não se perde ao longo do caminho) e para pior (uma mudança mal isolada se espalha com a mesma rapidez). É um compromisso, não uma solução mágica — e é exatamente por isso que documentamos a arquitetura real em vez de um resumo de marketing.

Esta página pilar contém links para as análises técnicas do cluster, à medida que são publicadas. Situação real no momento da publicação desta página — os links tornam-se ativos assim que o artigo correspondente estiver online.

Cluster A – Estrutura e arquitetura

Axum vs Actix-web: qual framework para um backend Rust em produção?Publicado

Arquitetura do espaço de trabalho de carga: como estruturar um backend Rust multisserviçoPublicado

Gateway de plano duplo: projetando um gateway de API de plano de dados/plano de gerenciamento em RustPublicado

Cluster B — API autogerada no Postgres

PostgREST: o que a compatibilidade realmente cobre e quais alternativas existemPublicado

API GraphQL nativa no Postgres com pg_graphql: o que Hasura e PostGraphile não fazem o mesmoPublicado

RLS e base dedicada por projeto: a escolha do isolamento multilocatário da AurabasePublicado

Cluster C – Tempo real e mensagens

Distribuir PostgreSQL CDC com NATS: arquitetura em tempo realPublicado

Cluster D – Edge Functions WebAssembly

Cluster E — Migração e alternativas

Migre um projeto Supabase para Aurabase sem reescrever suas políticas RLSPublicado

Auto-hospedagem soberana: posicionando Aurabase contra BaaS nativo de RustEm breve