En l’ecosistema de desenvolupament backend amb Node.js, l’extensibilitat s’ha convertit en un factor crític per triar un framework. Tant NestJS com Ditsmod, inspirats en l’arquitectura d’Angular, ofereixen mecanismes per construir aplicacions modulars i escalables. Tanmateix, quan es tracta de crear plugins complexos, generadors d’OpenAPI o integracions amb serveis cloud com AWS o Azure, les diferències es tornen notòries. En aquest article analitzem en profunditat els mòduls dinàmics, els proveïdors dinàmics i els grups d’extensió, dos enfocaments que comparteixen arrels però divergeixen en execució.
NestJS, el framework més popular de l’ecosistema, adopta el patró de mòduls dinàmics tal com ho fa Angular. Un mòdul dinàmic es construeix mitjançant un mètode estàtic que rep configuració en temps d’importació i retorna un objecte amb proveïdors, exportacions i el mateix mòdul. Això permet injectar valors com cadenes de connexió o claus d’API de manera còmoda. Però quan necessitem alguna cosa més complexa —com escanejar tota l’aplicació buscant decoradors personalitzats per generar documentació Swagger o afegir interceptors dinàmicament—, NestJS recorre al DiscoveryService i a ganxos de cicle de vida com OnModuleInit. Aquest enfocament funciona, però implica que la lògica d’infraestructura s’executa després que el contenidor DI està completament construït, cosa que limita la possibilitat de mutar l’arbre de dependències. En aplicacions empresarials que integren intel·ligència artificial o agents IA, aquesta limitació pot traduir-se en codi dispers i difícil de mantenir.
D’altra banda, Ditsmod v3.0 introdueix un sistema d’extensions que opera en una fase prèvia a l’arrencada de l’aplicació, similar a un temps de compilació. Les extensions implementen fins a tres ganxos seqüencials: stage1, stage2 i stage3. A stage1, que s’executa mentre encara s’estan muntant els arrays de proveïdors, l’extensió pot llegir metadades dels mòduls i, sobre la marxa, inserir nous proveïdors a les capes adequades (providersPerApp, providersPerMod, providersPerRou, providersPerReq). Això permet, per exemple, que un generador d’OpenAPI afegeixi automàticament un interceptor de validació a una ruta específica sense necessitat d’escanejar després de l’inici. La veritable innovació són els grups d’extensió: diverses extensions independents poden unir-se a un grup liderat per una extensió principal, compartint un contracte d’interfície comú. D’aquesta manera, quan l’extensió líder sol·licita les dades de stage1 al gestor d’extensions, rep un payload agregat amb les contribucions de tots els membres. Aquest mecanisme elimina la necessitat d’un DiscoveryService global i permet construir infraestructura col·laborativa —com encaminament dinàmic, metadades de seguretat o lògica de ciberseguretat— de manera desacoblada.
En el context de Q2BSTUDIO, una empresa dedicada al desenvolupament d’aplicacions a mida, aquestes decisions tècniques impacten directament en la qualitat del producte final. Quan treballem amb clients que requereixen integracions cloud a AWS o Azure, solucions de Business Intelligence amb Power BI, o sistemes d’automatització potenciats per agents IA, la capacitat d’estendre el framework sense trencar l’arquitectura és essencial. Amb NestJS, aconseguir una personalització profunda sovint implica sacrificar la netedat del codi o recórrer a pegats. Amb Ditsmod, en canvi, els grups d’extensió permeten que cada funcionalitat —des d’un mòdul de ciberseguretat fins a un pipeline de dades per a BI— s’integri com un plugin independent que col·labora amb els altres sota el mateix contracte.
Per il·lustrar-ho, imaginem un escenari típic en una plataforma SaaS: necessitem registrar metadades d’auditoria a cada ruta, generar documentació OpenAPI automàtica i validar les dades d’entrada amb un esquema personalitzat. A NestJS, hauríem de crear un guardia global, un interceptor i un decorador de rutes, i després coordinar-los mitjançant el DiscoveryService a OnModuleInit. A Ditsmod, podem definir una extensió principal 'AuditRouteExtension' que a stage1 recull els decoradors de cada mòdul i, si detecta un decorador d’auditoria, insereix un proveïdor d’interceptor a providersPerRou. Una altra extensió, 'OpenApiExtension', s’uneix al grup de l’extensió principal i al mateix stage1 afegeix metadades de ruta a un array compartit. Al final, el gestor d’extensions lliura un payload unificat que l’extensió principal pot consumir per generar la documentació o habilitar l’auditoria. Tot això passa abans que l’aplicació atengui la primera petició, cosa que garanteix un arrencada neta i previsible.
Des d’una perspectiva empresarial, l’elecció entre NestJS i Ditsmod no és trivial. Si el teu equip ja té experiència amb NestJS i les necessitats d’extensibilitat són bàsiques (inyecció de configuració, mòduls dinàmics simples), NestJS continua sent una opció sòlida i amb una comunitat enorme. Però si apuntes a aplicacions modulars on terceres parts puguin aportar funcionalitats sense trencar el nucli, o si necessites una integració profunda amb sistemes d’IA, ciberseguretat o BI, el sistema d’extensions de Ditsmod proporciona una base més sòlida. A Q2BSTUDIO, on dissenyem arquitectures per a clients que busquen aplicacions a mida amb alts estàndards de qualitat, valorem especialment la capacitat de Ditsmod de mantenir el contenidor DI obert durant la fase d’inicialització, permetent a cada mòdul contribuir a l’ecosistema sense acoblament.
En conclusió, tant NestJS com Ditsmod hereten l’elegància d’Angular en la gestió de mòduls dinàmics i proveïdors dinàmics. Tanmateix, quan l’extensibilitat es converteix en el centre de l’arquitectura —ja sigui per integrar agents IA, automatitzar processos o desplegar en núvos híbrides—, Ditsmod ofereix una capa addicional de control amb els seus grups d’extensió. L’elecció final dependrà de la complexitat del teu projecte i de la maduresa del teu equip. Però sens dubte, entendre aquestes diferències és clau per construir programari que evolucioni sense dolor.
