node-server. Esta arquitectura monolítica simplifica el despliegue en servidores VPS sin necesidad de un backend separado.
Capas de la Aplicación
La aplicación se divide en tres capas bien delimitadas que interactúan entre sí a través de la capa de transporte HTTP.Frontend (Vue 3 + Nuxt UI)
La interfaz de usuario reside bajo el directorioapp/ siguiendo la convención de Nuxt 4:
Los estilos globales se importan desde
app/assets/css/main.css mediante la clave css de nuxt.config.ts. El alias @ apunta al directorio app/.
Servidor (Nitro)
El servidor corre sobre Nitro en modonode-server. Todos sus artefactos se encuentran bajo server/:
El servidor también expone contexto asíncrono mediante
nitro.experimental.asyncContext: true, lo que permite acceder al event de H3 desde servicios anidados sin pasarlo explícitamente.
Base de Datos (Prisma + MariaDB)
La capa de persistencia utiliza Prisma ORM con una base de datos MariaDB:
El
DATABASE_ENV en runtimeConfig determina qué URL de conexión se usa (DATABASE_URL_DEV o DATABASE_URL_PRO).
Rutas de la Aplicación
Las rutas bajo
/dash/* y /admin/* son protegidas tanto por el middleware del cliente (app/middleware/auth.ts) como por el middleware del servidor (server/middleware/auth.ts y server/middleware/admin.ts).Servicios del Servidor
Los servicios se instancian como funciones factoría (serviceFactory()) para facilitar las pruebas unitarias y la inyección de dependencias.
Directivas de Rutas
La claverouteRules en nuxt.config.ts controla el comportamiento de renderizado por ruta:
isr: false en /dash/** deshabilita el Incremental Static Regeneration para todas las páginas del dashboard del afiliado, garantizando que siempre se sirvan como SSR dinámico (nunca desde caché estática).
El bloque nitro.prerender excluye explícitamente las rutas autenticadas del proceso de pre-renderizado en build:
Módulo nohup (Daemon)
El directorioserver/nohup/ contiene un proceso independiente de Node.js que no requiere que el servidor Nuxt esté en ejecución. Su único propósito actual es consultar periódicamente la API de FirmaPlus para monitorear el estado de las solicitudes de crédito enviadas a firma digital.
Ciclo de trabajo:
- Arranca con
tsx server/nohup/app.ts(opnpm nohup:firmas:daemonen segundo plano). - Consulta en base de datos todas las solicitudes con
estado = "PENDIENTE_FIRMADO". - Por cada solicitud lanza un
Workerde Node.js (consultar-firma.worker.ts) que llama aGET consultarsolicitud/{numero_solicitud}en FirmaPlus. - Registra el resultado en
storage/logs/app.log. - Espera 5 minutos (
INTERVAL_MS = 5 * 60 * 1000) y repite el ciclo.
El daemon solo consulta y registra en logs. No modifica estados en la base de datos en la implementación actual. La lógica de transición de estados puede añadirse en
workers/consultar-firma.worker.ts sin alterar el loop principal.Autenticación y Autorización
Flujo JWT, sesiones con nuxt-auth-utils, middleware de servidor y protección de rutas.
Almacenamiento de Archivos
Uploads locales, servicio SFTP, tipos MIME permitidos y rutas de acceso a documentos.