harness

Cratefield Harness es el núcleo de código abierto con licencia MIT detrás de Cratefield, un arnés de backend en Rust a partir del cual se compila su propio backend. La premisa establecida es que todo producto necesita un backend y casi ninguno debería construirse desde cero, por lo que este es ese backend, una sola vez. Usted elige crates de módulos, conecta adaptadores y despliega un Worker sin estado con su propia base de datos. Modelo de composición. Un proyecto declara un constructor de Harness con una identidad de proyecto, URL pública y orígenes CORS, añade módulos y selecciona un runtime con su vinculación de base de datos, proveedores de correo y captcha. El proceso de construcción rechaza un módulo que requiera un puerto que el runtime no proporcione, dos módulos que reclamen la misma tabla o ruta, o un módulo construido contra una versión de contrato diferente. La plantilla del proyecto ejecuta la composición bajo cargo test, por lo que cualquier configuración errónea falla antes del despliegue. Módulos y puertos. Un módulo es un crate que implementa el trait Module y se monta en una ruta versionada por nombre de módulo. Declara su nombre, puertos requeridos, migraciones (SQL embebido vía include_str!, en un subconjunto aceptado tanto por SQLite como por Postgres) y un router de axum. Los módulos nunca tocan vinculaciones de proveedores, variables de entorno o clientes de proveedores; solicitan puertos como Database, Mailer, Captcha, RateLimiter, Signer y KeyValue, y los adaptadores responden. Según el README, esa regla única es lo que hace que alejarse de Cloudflare sea un cambio de un solo crate de runtime. Crates incluidos. La fachada cratefield; cratefield-core con el trait Module, el constructor de Harness, traits de puerto, errores problem+json, alcance de solicitud, bus de eventos y plantillas; cratefield-runtime-cloudflare; adaptadores para correo de Resend, captcha de Turnstile y SQLite vía rusqlite; módulos email-signup con doble opt-in, baja y exportación de administrador, y waitlist con confirmación, posición y códigos de referido; cratefield-secrets con secretos cifrados mediante sobres sobre el puerto Database; cratefield-kms para envolver y desenvolver claves de datos, con un proveedor de archivo local que rechaza la producción; cratefield-ui, que renderiza la superficie del módulo como HTML en /ui; cratefield-cli que expone el binario fz con comandos de recolección de migraciones, doctor y módulos; y cratefield-testing, un kit de conformidad que cada módulo debe superar. Los crates planeados son cratefield-adapter-postgres sobre sqlx y cratefield-runtime-native en tokio. Migraciones y solicitudes. Las consultas pasan por sea-query para que se rendericen para cualquiera de las bases de datos. Los enlaces de confirmación y baja son tokens firmados con HMAC con rotación de claves, por lo que no hay almacén de sesiones. El alcance de la solicitud viaja en extensiones de axum en lugar de un estado compartido, y el kit de conformidad incluye una prueba de solicitudes concurrentes que lo verifica. Montaje. Un módulo se compila en el Worker, que es el valor predeterminado, o se ejecuta como un sidecar con su propio Worker construido y desplegado por separado y montado en la misma ruta sobre una vinculación de servicio con la misma base de datos y secretos. El README indica que la opción de sidecar está diseñada pero no construida. Observabilidad. Un span estructurado por solicitud lleva request_id, método, ruta, módulo, estado, duration_ms, ip_hash y ua_family, y nunca una dirección de correo electrónico. Workers Logs está habilitado en el wrangler.toml de la plantilla y las respuestas hacen eco de x-request-id. La taxonomía de errores se genera desde el registro central y se verifica la deriva en CI. Hoja de ruta según el repositorio. M0 base (herramientas de espacio de trabajo, core, runtime de Cloudflare, adaptadores de Resend y Turnstile, adaptador de SQLite, fz, kit de pruebas), M1 primeros módulos, M2 primer proyecto en vivo con publicación en crates.io, documentación y versionado de contratos, marcado como en progreso, y M3 portabilidad auto-alojada con el adaptador de Postgres, runtime nativo, suite de paridad y migración de datos. Se especifican tres épicas adicionales pero no programadas. Cadena de herramientas y estado. Rust estable fijado en rust-toolchain.toml, objetivo wasm32-unknown-unknown, worker-build y wrangler; CI ejecuta fmt, clippy con advertencias denegadas, pruebas, cargo deny, y construye el proyecto de ejemplo a wasm para que una dependencia solo nativa no se filtre en un módulo. Los crates aún no se han publicado en crates.io, por lo que el README aconseja depender del repositorio mediante git. Los crates privados están marcados como publish = false en lugar de vivir en un repositorio separado. Licencia: MIT.