Arquitectura

BloomX se compone de N frontends (una app Next.js por empresa o dominio) y un backend compartido multi-tenant. Cada frontend es dueño de sus usuarios, correos y base de datos; el backend compartido aporta el registro de dominios, la configuración de marca, el catálogo y la ejecución de extensiones, y los pagos.

Visión general#

• Frontend (bloomx): interfaz, API propia (/api/*), base de datos PostgreSQL propia (DATABASE_URL), almacenamiento de adjuntos y el envío/recepción por Resend.
• Backend compartido (bloomx-backend): GET /api/config (marca y extensiones del dominio), registro (/api/auth/register, register-domain, verify-domain), instalación de extensiones, ejecución sandboxed de extensiones (/api/extension/execute, /api/extension/hooks), pagos y el almacén público de logos.
• Servicios externos: PostgreSQL (por ejemplo Neon), S3/B2/R2, Resend, Upstash Redis (opcional para rate limit distribuido) y, si los activas, Google/Zoom/Slack/Notion/HubSpot/Trello por OAuth.

Backend compartido y multi-tenant#

• Alta abierta: cualquiera puede registrar un manager (POST /api/auth/register) o un dominio (POST /api/auth/register-domain + POST /api/auth/verify-domain con un OTP de 6 dígitos enviado por correo; con límites de intentos). Para un despliegue privado desactiva el alta con ALLOW_OPEN_REGISTRATION=false en el backend.
• **CORS * intencional**: el backend responde siempre Access-Control-Allow-Origin: * y sin credenciales. No es un agujero: la autenticación no usa cookies del navegador sino firmas por dominio (las cookies de manager de Lucia solo las usa el panel de gestión de dominio). No existe variable para restringirlo.
• Un dominio = un tenant: el tenant se identifica por la cabecera X-BloomX-Domain. Cada tenant tiene su marca (Domain.theme), sus extensiones instaladas, sus credenciales de extensión cifradas y, opcionalmente, su clave pública Ed25519.

Confianza sin secretos globales#

Frontend y backend no comparten ningún secreto. Esto permite que cualquier empresa levante su frontend sin coordinar claves con el operador del backend:

Modo firmado frente a modo legado#

Flujo del correo#

• Entrante: Resend recibe (registro MX de tu dominio) y llama a POST /api/webhooks/resend. Si defines WEBHOOK_SECRET se exige firma Svix válida; sin él se acepta sin firma (cada organizador decide). El frontend guarda el correo en PostgreSQL y los adjuntos en el almacenamiento, procesa adjuntos en segundo plano y notifica a la interfaz por SSE.
• Saliente: la interfaz llama a POST /api/emails, que valida propiedad del remitente, límites y adjuntos, ejecuta el hook EMAIL_PRE_SEND (DLP) contra el backend y envía por Resend con Idempotency-Key.
• Eventos: rebotes y quejas llegan a POST /api/webhooks/resend-events (con RESEND_WEBHOOK_SECRET opcional) y alimentan la lista de supresión.
• Gmail/Outlook/IMAP no están soportados como buzones: el correo entra por Resend. Sí existe sincronización de calendario y contactos de Google.

Datos y estado#

• Frontend: PostgreSQL vía Prisma más SQL crudo. El esquema se garantiza con npm run db:ensure (aditivo, con advisory locks). Ver Operación.
• Backend: PostgreSQL propio (dominios, managers, extensiones, instalaciones, transacciones). Su esquema se aplica con npm run prisma:push.
• Adjuntos y activos: S3-compatible; en el frontend S3_*, en el backend B2_*. Se sirven mediante URLs firmadas. Ver Almacenamiento.
• Estado efímero: nonces anti-replay y rate limit en memoria por instancia (el rate limit del frontend puede ser global con Upstash).

Fronteras de seguridad#

• El navegador solo habla con su frontend; el frontend firma cuando habla con el backend.
• Las extensiones corren en el backend, dentro de un sandbox worker_threads, con red filtrada (safe-fetch). No es una frontera fuerte: ver Extensiones.
• Los secretos de terceros (claves de Resend por dominio, credenciales de extensiones) se cifran en el backend con DATA_ENCRYPTION_KEY y nunca vuelven al navegador.
• Detalle completo en Seguridad.