Cron, datos y PDF: tres fronteras para informes semanales
Separar el calendario, los datos y el renderizado en tres contratos, con un job idempotente que los une, evita duplicados y deja claro quién es dueño de la plantilla.
Montar un informe semanal en PDF parece una sola función hasta que alguien reejecuta el job. Ahí salen las preguntas incómodas: ¿ya se generó este periodo?, ¿qué revisión de plantilla produjo el PDF que hay guardado?, ¿puede un operador regenerar uno suelto sin esperar siete días? Ninguna de esas preguntas es de renderizado; todas son de estado y de propiedad. Un patrón habitual para resolverlo parte el pipeline en tres contratos y deja que un único job idempotente los componga.
Tres piezas con contratos cerrados
ReportSource carga y normaliza los datos de un periodo. TemplateRenderer produce el HTML y arrastra la revisión exacta de la plantilla que lo generó. PdfRenderer convierte un HTML ya completo en bytes de PDF. Almacenamiento y planificación se quedan fuera de esos tres porque son mecánica de entrega. La dirección de dependencias queda aburrida, que en herramientas de desarrollo es un elogio.
El adaptador de cron y una ruta de Express autenticada invocan el mismo caso de uso, y ese caso de uso escribe contra una sola interfaz de almacenamiento. No hay una segunda implementación de generación manual esperando a desviarse de la primera. La clave del objeto es determinista —periodo de inicio más periodo de fin— y el almacén expone una operación que crea o informa de que el documento ya existía, con lo que una reejecución no duplica el PDF. Un PDF de longitud cero se trata como error explícito, no como caso raro que se cuela en producción.
Quién es dueño de la plantilla
Esa es la restricción que decide la arquitectura, y no se arregla después con otro fichero de configuración. Si la plantilla la llevan los desarrolladores, va versionada junto al código de la aplicación: revisión y rollback son triviales, pero cada cambio de redacción exige un despliegue. Si la lleva un equipo de diseño, conviene un paquete de plantillas versionado aparte, y entonces la compatibilidad de ese paquete entra en el control de versiones del release. Si la lleva el cliente, toca un servicio de plantillas acotado o un esquema almacenado, y la validación, el aislamiento y la previsualización pasan a ser funcionalidades de producto.
Conviene no leer esa última fila como "aceptamos HTML arbitrario". Eso no es delegar la plantilla: es política de ejecución y de recursos disfrazada de campo de texto.
Bundles y pruebas
Un bundle semanal fusionado es una lista ordenada de artefactos ya renderizados, no una plantilla gigante con fragmentos condicionales. Un split es una operación de índice sobre un bundle que ya existe, con nombres de salida y rangos de página explícitos. Y aunque el PDF esté estandarizado en ISO 32000-2, eso no vuelve portable cualquier maquetación HTML: el renderizador sigue siendo una frontera real del sistema, así que su salida merece comprobaciones con ficheros de referencia en lugar de fe.
Lo que queda por ver es cuánto aguanta el patrón cuando cambia el dueño de la plantilla. Mover esa frontera es un cambio de arquitectura, no de configuración.
