En el ecosistema del desarrollo backend con Node.js, la extensibilidad se ha convertido en un factor crítico para elegir un framework. Tanto NestJS como Ditsmod, inspirados en la arquitectura de Angular, ofrecen mecanismos para construir aplicaciones modulares y escalables. Sin embargo, cuando se trata de crear plugins complejos, generadores de OpenAPI o integraciones con servicios cloud como AWS o Azure, las diferencias se vuelven notorias. En este artículo analizamos en profundidad los módulos dinámicos, los proveedores dinámicos y los grupos de extensión, dos enfoques que comparten raíces pero divergen en ejecución.
NestJS, el framework más popular del ecosistema, adopta el patrón de módulos dinámicos tal como lo hace Angular. Un módulo dinámico se construye mediante un método estático que recibe configuración en tiempo de importación y devuelve un objeto con proveedores, exportaciones y el propio módulo. Esto permite inyectar valores como cadenas de conexión o claves de API de forma cómoda. Pero cuando necesitamos algo más complejo —como escanear toda la aplicación en busca de decoradores personalizados para generar documentación Swagger o agregar interceptores dinámicamente—, NestJS recurre al DiscoveryService y a ganchos de ciclo de vida como OnModuleInit. Este enfoque funciona, pero implica que la lógica de infraestructura se ejecuta después de que el contenedor DI está completamente construido, lo que limita la posibilidad de mutar el árbol de dependencias. En aplicaciones empresariales que integran inteligencia artificial o agentes IA, esta limitación puede traducirse en código disperso y difícil de mantener.
Por otro lado, Ditsmod v3.0 introduce un sistema de extensiones que opera en una fase previa al arranque de la aplicación, similar a un tiempo de compilación. Las extensiones implementan hasta tres ganchos secuenciales: stage1, stage2 y stage3. En stage1, que se ejecuta mientras aún se están ensamblando los arreglos de proveedores, la extensión puede leer metadatos de los módulos y, sobre la marcha, insertar nuevos proveedores en las capas adecuadas (providersPerApp, providersPerMod, providersPerRou, providersPerReq). Esto permite, por ejemplo, que un generador de OpenAPI agregue automáticamente un interceptor de validación a una ruta específica sin necesidad de escanear después del inicio. La verdadera innovación son los grupos de extensión: varias extensiones independientes pueden unirse a un grupo liderado por una extensión principal, compartiendo un contrato de interfaz común. De esta forma, cuando la extensión líder solicita los datos de stage1 al gestor de extensiones, recibe un payload agregado con las contribuciones de todos los miembros. Este mecanismo elimina la necesidad de un DiscoveryService global y permite construir infraestructura colaborativa —como enrutamiento dinámico, metadatos de seguridad o lógica de ciberseguridad— de manera desacoplada.
En el contexto de Q2BSTUDIO, una empresa dedicada al desarrollo de aplicaciones a medida, estas decisiones técnicas impactan directamente en la calidad del producto final. Cuando trabajamos con clientes que requieren integraciones cloud en AWS o Azure, soluciones de Business Intelligence con Power BI, o sistemas de automatización potenciados por agentes IA, la capacidad de extender el framework sin romper la arquitectura es esencial. Con NestJS, lograr una personalización profunda a menudo implica sacrificar la limpieza del código o recurrir a parches. Con Ditsmod, en cambio, los grupos de extensión permiten que cada funcionalidad —desde un módulo de ciberseguridad hasta un pipeline de datos para BI— se integre como un plugin independiente que colabora con los demás bajo un mismo contrato.
Para ilustrarlo, imaginemos un escenario típico en una plataforma SaaS: necesitamos registrar metadatos de auditoría en cada ruta, generar documentación OpenAPI automática y validar los datos de entrada con un esquema personalizado. En NestJS, deberíamos crear un guardia global, un interceptor y un decorador de rutas, y luego coordinarlos mediante el DiscoveryService en OnModuleInit. En Ditsmod, podemos definir una extensión principal 'AuditRouteExtension' que en stage1 recolecta los decoradores de cada módulo y, si detecta un decorador de auditoría, inserta un proveedor de interceptor en providersPerRou. Otra extensión, 'OpenApiExtension', se une al grupo de la extensión principal y en el mismo stage1 agrega metadatos de ruta a un array compartido. Al final, el gestor de extensiones entrega un payload unificado que la extensión principal puede consumir para generar la documentación o habilitar la auditoría. Todo esto sucede antes de que la aplicación maneje la primera petición, lo que garantiza un arranque limpio y predecible.
Desde una perspectiva empresarial, la elección entre NestJS y Ditsmod no es trivial. Si tu equipo ya tiene experiencia con NestJS y las necesidades de extensibilidad son básicas (inyección de configuración, módulos dinámicos simples), NestJS sigue siendo una opción sólida y con una comunidad enorme. Pero si apuntas a aplicaciones modulares donde terceras partes puedan aportar funcionalidades sin romper el core, o si necesitas una integración profunda con sistemas de IA, ciberseguridad o BI, el sistema de extensiones de Ditsmod proporciona una base más sólida. En Q2BSTUDIO, donde diseñamos arquitecturas para clientes que buscan aplicaciones a medida con altos estándares de calidad, valoramos especialmente la capacidad de Ditsmod para mantener el contenedor DI abierto durante la fase de inicialización, permitiendo a cada módulo contribuir al ecosistema sin acoplamiento.
En conclusión, tanto NestJS como Ditsmod heredan la elegancia de Angular en el manejo de módulos dinámicos y proveedores dinámicos. Sin embargo, cuando la extensibilidad se vuelve el centro de la arquitectura —ya sea para integrar agentes IA, automatizar procesos o desplegar en nubes híbridas—, Ditsmod ofrece una capa adicional de control con sus grupos de extensión. La elección final dependerá de la complejidad de tu proyecto y de la madurez de tu equipo. Pero sin duda, entender estas diferencias es clave para construir software que evolucione sin dolor.
