Sobre o projeto

Cratefield Harness é o núcleo open-source com licença MIT por trás do Cratefield, um harness de backend em Rust a partir do qual você compila seu próprio backend. A premissa declarada: todo produto precisa de um backend e quase nenhum deve ser construído do zero, então este é esse backend, de uma vez por todas. Você escolhe crates de módulos, conecta adaptadores e envia um Worker stateless com seu próprio banco de dados. Modelo de composição. Um venture declara um construtor Harness com uma identidade de venture, URL pública e origens CORS, adiciona módulos e seleciona um runtime com seu binding de banco de dados, provedores de mailer e captcha. O build recusa um módulo que requer uma porta que o runtime não fornece, dois módulos reivindicando a mesma tabela ou rota, ou um módulo construído contra uma versão de contrato diferente. O template do venture executa a composição sob cargo test, portanto, a configuração incorreta falha antes do deploy. Módulos e portas. Um módulo é uma crate que implementa a trait Module e é montado em um caminho versionado por nome de módulo. Ele declara seu nome, portas requeridas, migrações (SQL incorporado via include_str!, em um subconjunto aceito tanto por SQLite quanto por Postgres) e um roteador axum. Módulos nunca tocam em bindings de fornecedor, variáveis de ambiente ou clientes de fornecedor; eles solicitam portas como Database, Mailer, Captcha, RateLimiter, Signer e KeyValue, e os adaptadores respondem. De acordo com o README, essa regra única é o que torna a migração do Cloudflare uma mudança de apenas uma crate de runtime. Crates incluídas. A facade cratefield; cratefield-core com a trait Module, construtor Harness, traits de porta, erros problem+json, escopo de requisição, barramento de eventos e templates; cratefield-runtime-cloudflare; adaptadores para e-mail Resend, captcha Turnstile e SQLite via rusqlite; módulos email-signup com double opt-in, unsubscribe e exportação de admin, e waitlist com confirmação, posição e códigos de indicação; cratefield-secrets com segredos criptografados por envelope sobre a porta Database; cratefield-kms para envolver e desvendar chaves de dados, com um provedor de arquivo local que recusa produção; cratefield-ui, que renderiza a superfície do módulo como HTML em /ui; cratefield-cli expondo o binário fz com comandos de coleta de migrações, doctor e módulos; e cratefield-testing, um kit de conformidade que cada módulo deve passar. Crates planejadas são cratefield-adapter-postgres via sqlx e cratefield-runtime-native no tokio. Migrações e requisições. As queries passam pelo sea-query para que sejam renderizadas para qualquer um dos bancos de dados. Links de confirmação e cancelamento de inscrição são tokens assinados via HMAC com rotação de chaves, portanto não há armazenamento de sessão. O escopo da requisição viaja em extensões axum em vez de estado compartilhado, e o kit de conformidade inclui um teste de requisição concorrente que verifica isso. Montagem. Um módulo é compilado no Worker, que é o padrão, ou executado como um sidecar com seu próprio Worker construído e implantado separadamente e montado no mesmo caminho via service binding com o mesmo banco de dados e segredos. O README afirma que a opção de sidecar foi projetada, mas não construída. Observabilidade. Um span estruturado por requisição carrega request_id, method, route, module, status, duration_ms, ip_hash e ua_family, e nunca um endereço de e-mail. Workers Logs está habilitado no template wrangler.toml e as respostas ecoam x-request-id. A taxonomia de erros é gerada a partir do registro core e verificada quanto a desvios no CI. Roadmap conforme declarado no repositório. M0 fundação (ferramentas de workspace, core, runtime Cloudflare, adaptadores Resend e Turnstile, adaptador SQLite, fz, kit de testes), M1 primeiros módulos, M2 primeiro venture live com publicação no crates.io, docs e versionamento de contrato, marcado como em progresso, e M3 portabilidade self-hosted com o adaptador Postgres, runtime nativo, suíte de paridade e movimentação de dados. Três épicos adicionais são especificados, mas não agendados. Toolchain e status. Rust Stable fixado em rust-toolchain.toml, target wasm32-unknown-unknown, worker-build e wrangler; o CI executa fmt, clippy com avisos negados, testes, cargo deny, e constrói o venture de exemplo para wasm para que uma dependência apenas nativa não possa entrar em um módulo. As crates ainda não foram publicadas no crates.io, portanto o README aconselha a dependência do repositório via git. Crates privadas são marcadas como publish = false em vez de residirem em um repositório separado. Licença: MIT.