En l'ecosistema actual d'aplicacions empresarials, la capacitat de gestionar correctament el cicle de vida d'un servei s'ha convertit en un requisit tan crític com el seu rendiment en producció. Quan un orquestrador de contenidors com Kubernetes decideix aturar un pod —ja sigui per un escalat automàtic, una actualització o una fallada— envia un senyal SIGTERM que l'aplicació ha d'interceptar per tancar connexions de base de dades, aturar processos en segon pla i evitar la corrupció de dades. Aquest procés, conegut com a apagat graceful, és el tema central d'aquesta anàlisi comparativa entre els frameworks Node.js més rellevants del moment: NestJS v12.0 i Ditsmod v3.0.
A Q2BSTUDIO, desenvolupem aplicacions a mida per a entorns cloud que requereixen alta disponibilitat i resiliència. La nostra experiència amb tecnologies com AWS, Azure, ciberseguretat, intel·ligència artificial i Business Intelligence ens ha ensenyat que un apagat incorrecte pot provocar pèrdues de dades i temps d'inactivitat que afecten directament el negoci. Per això, entendre com gestionen NestJS i Ditsmod el cicle de vida i l'apagat graceful és fonamental per escollir l'eina adequada a cada projecte.
NestJS ofereix un sistema madur de hooks de cicle de vida. Els desenvolupadors poden implementar interfícies com OnModuleInit o OnApplicationBootstrap per executar lògica en arrencar, i hooks com OnModuleDestroy, BeforeApplicationShutdown i OnApplicationShutdown per a l'apagat. No obstant això, NestJS requereix que s'activi explícitament l'escolta de senyals mitjançant app.enableShutdownHooks() al fitxer main.ts. Un cop habilitat, el framework recorre tot l'arbre de proveïdors del contenidor d'injecció de dependències i executa els hooks corresponents. Això, tot i ser funcional, pot ser ineficient en aplicacions grans: fins i tot serveis que mai van ser instanciats o que són d'àmbit per sol·licitud (request-scoped) són considerats, afegint latència innecessària al procés d'apagat. A més, si algun hook llança una excepció no controlada, el procés pot quedar penjat o avortar abruptament, posant en risc la integritat de les dades.
Ditsmod, per la seva banda, adopta un enfocament més estricte i optimitzat. També requereix la crida a app.enableShutdownHooks(), però la seva implementació interna està dissenyada per minimitzar el temps d'apagat i garantir la tolerància a fallades. Ditsmod executa una seqüència de tres passos perfectament definits: primer, invoca el hook beforeShutdown() en tots els serveis singleton que hagin estat realment instanciats durant l'execució. Això permet aturar temporitzadors, cues de treball o agents d'IA abans que el servidor HTTP deixi d'acceptar connexions. Segon, el mètode customShutdown(signal) —que en aplicacions REST és sobrescrit per RestApplication— tanca el servidor HTTP, deixa de rebre noves connexions i espera que les peticions en curs finalitzin dins d'un temps d'espera configurable (per defecte 15 segons). Finalment, s'executa el hook onShutdown() en els serveis singleton, moment segur per tancar connexions a bases de dades, sistemes de fitxers o serveis cloud com Azure Blob Storage.
Una diferència clau és que Ditsmod només executa hooks en instàncies singleton que hagin estat creades. Els proveïdors d'àmbit per sol·licitud o per ruta s'ignoren completament, cosa que estalvia temps de processament i evita instanciar dependències innecessàries només per apagar-les. A més, Ditsmod executa tots els hooks de forma concurrent usant Promise.allSettled(), de manera que un error en un servei (per exemple, una fallada en la connexió a Redis) no bloqueja el tancament d'altres serveis (com PostgreSQL o un agent d'IA). Els errors es registren a través de SystemLogMediator sense interrompre el flux general.
En el context empresarial, aquestes diferències tenen implicacions directes. Per a equips que busquen un framework amb ecosistema ampli i documentació extensa, NestJS continua sent l'opció més segura. No obstant això, quan l'eficiència i la predictibilitat de l'apagat són crítiques —per exemple, en microserveis que gestionen dades financeres o sistemes de ciberseguretat que han de garantir la integritat de registres d'auditoria—, Ditsmod ofereix un control més granular i un rendiment superior. A Q2BSTUDIO oferim serveis cloud a AWS i Azure que integren aquestes decisions tècniques per optimitzar el cicle de vida de les aplicacions. També apliquem intel·ligència artificial i agents IA per automatitzar el monitoratge de l'estat dels serveis, i utilitzem eines de BI com Power BI per visualitzar mètriques d'apagat i disponibilitat.
L'elecció entre NestJS i Ditsmod no és trivial. Ambdós frameworks representen filosofies diferents: NestJS prioritza la facilitat d'ús i la maduresa de l'ecosistema; Ditsmod, la puresa arquitectònica i el rendiment en escenaris extrems. L'important és comptar amb un soci tecnològic que entengui aquestes diferències i pugui adaptar la solució a les necessitats específiques del negoci. A Q2BSTUDIO, combinem la nostra experiència en desenvolupament de programari a mida, ciberseguretat, cloud computing, intel·ligència artificial i Business Intelligence per construir sistemes robustos que no només arrenquin bé, sinó que també s'apaguin de forma segura i predictible.
