Arquitectura Híbrida en el Edge: Rediseño de la Intranet de DP-FIRE

1. El Desafío Operativo e Infraestructural

La intranet y sistema de gestión de DP-FIRE Chile SpA centraliza operaciones críticas de logística, control de inventarios corporativos e inspecciones vehiculares multi-empresa. Anteriormente, el backend consistía en una API Express monolítica corriendo en Render (con un costo mensual fijo de $7.00 USD).

El cuello de botella principal de la empresa eran los informes logísticos y reportes en matrices de Excel que se manejaban manualmente. Al automatizar estos procesos, nos enfrentamos a dos desafíos críticos:

1. Reducir a cero ($0.00 USD) los costes fijos de infraestructura mensual para el hosting y base de datos de la intranet.
2. Sortear los límites físicos del Edge computing. Aunque queríamos migrar todo a Serverless en Cloudflare Workers, la generación de PDFs y planillas Excel consume mucha CPU y excede los límites impuestos.

2. La Solución: Arquitectura Edge Híbrida

Para solucionar esto, diseñamos una arquitectura híbrida de microservicios alojada en un monorepo administrado con pnpm workspaces.

graph TD
    Client[Client: React SPA] -->|Requests| Gateway[Gateway: Cloudflare Worker Hono]
    
    Gateway -->|/auth & /virtual-library| EdgeRoutes[Edge Native: Web Crypto & R2]
    Gateway -->|Other Routes: /users, /rems, /products| Express[Express Backend: api-reports]
    
    EdgeRoutes -->|Drizzle ORM| Turso[Turso DB: SQLite Edge]
    Express -->|Drizzle ORM| Turso

2.1. Separación de Responsabilidades en el Edge (Cloudflare Workers vs. Node/Express)

Cloudflare Workers ofrece una capa gratuita generosa pero impone un límite estricto de 10ms de tiempo de ejecución de CPU por petición.

• Tareas comunes como flujos criptográficos ligeros (firmas o verificación de tokens de seguridad) y redirección de imágenes a R2 tardan microsegundos y son perfectas para Workers.
• Tareas pesadas como la generación de certificados PDF (pdfkit) y la exportación de planillas de reportes Excel (exceljs) consumen CPU de forma intensa, tardando entre 100ms y 1.5s.

La Solución: Dividimos el backend en dos bloques funcionales:

1. api-core (Cloudflare Workers + Hono): Resuelve la autenticación, rutas del Edge nativas y control de acceso en microsegundos, alojado de manera gratuita ($0 USD).
2. api-reports (Node.js + Express en Railway): Se encarga de la generación pesada de documentos. Railway opera bajo un modelo de cobro por uso activo (solo cobra cuando se realizan peticiones), reduciendo a prácticamente cero los costes durante los periodos de inactividad de la empresa.

Ambos servicios se conectan a Turso (libSQL) mediante Drizzle ORM, una base de datos distribuida en el Edge con réplicas de baja latencia y con coste mensual de $0 USD en su capa gratuita.

2.2. Clean Architecture (Puertos y Adaptadores)

Para independizar las reglas de negocio de los proveedores externos de infraestructura (como R2, AWS S3 o discos duros locales), implementamos el patrón de Puertos y Adaptadores (Ports & Adapters):

• El Puerto (Interface): Una interfaz abstracta StorageService que expone funciones como uploadFile() y deleteFile().
• El Adaptador (Implementation): Implementamos un adaptador concreto S3StorageService que utiliza el SDK oficial para interactuar con Cloudflare R2 o AWS S3.
• Beneficio: Si en el futuro decidimos cambiar de Cloudflare R2 a Google Cloud Storage o a un disco local, no tocaremos una sola línea de código de lógica de negocio; solo cambiaremos el adaptador.

2.3. Principios de Ingeniería Aplicados

• Domain-Driven Design (DDD): El monorepo de backend está estructurado en torno a Límites de Dominio (Bounded Contexts) como /auth, /users, /companies, /rems y /certificates. Cada contexto agrupa de manera aislada sus esquemas de Drizzle ORM, DTOs y servicios de dominio.
• Test-Driven Development (TDD): Usamos Vitest Projects para configurar un arnés de pruebas automáticas. Validamos la compatibilidad criptográfica de tokens y la consistencia de base de datos antes del despliegue.
• CI/CD Automatizado: Tubería de integración continua en GitHub Actions que ejecuta en cada push/pull-request tareas de formateo, linting, análisis de código muerto (knip) y compilación rigurosa de TypeScript.

3. Impacto de la Reestructuración

• Optimización Financiera: Pasamos de un costo fijo mensual de $7.00 USD (Render) a un costo operativo base de $0.00 USD fijos en hosting de API y base de datos (con Railway cobrando solo fracciones de centavos en base a uso activo).
• Rendimiento: Las operaciones cotidianas de la intranet resuelven sus consultas en milisegundos gracias a la base de datos de Turso en el Edge.
• Mantenibilidad: El desacoplamiento y los principios de código limpio aseguran que agregar nuevas funcionalidades al monorepo sea ágil y libre de regresiones.