L'ecosistema Node.js avança sense pausa, i dos dels seus frameworks més prometedors —NestJS i Ditsmod— estan a punt de fer un salt generacional amb les versions 12.0 i 3.0 respectivament. Ambdos aborden problemes centrals del desenvolupament backend modern: la migració definitiva a Mòduls ECMAScript (ESM), la validació de paràmetres i l'execució de peticions. Però ho fan des de filosofies molt diferents. A Q2BSTUDIO, on desenvolupem aplicacions a mida que integren intel·ligència artificial, ciberseguretat i cloud, entenem que l'elecció del framework pot marcar la diferència en l'escalabilitat i el manteniment d'un projecte. Analitzem ambdues propostes des d'una perspectiva tècnica i pràctica, sense copiar fullets oficials.
Migració ESM: el final del limbe CommonJS Durant anys, els desenvolupadors hem navegat entre CommonJS i ESM, patint configuracions híbrides i builds redundants. NestJS 12.0 aposta fort per l'ESM natiu, abandonant gradualment eines clàssiques: Vitest substitueix Jest, oxlint substitueix ESLint i Rspack substitueix Webpack. Això promet una experiència unificada en monorepos, on frontend i backend comparteixen el mateix sistema de mòduls. No obstant, aquesta migració encara requereix certa adaptació en projectes legacy. Per la seva banda, Ditsmod va néixer amb ESM com a base, utilitzant await top-level des de l'arrencada (await RestApplication.create(AppModule)). La seva integració amb Vitest és directa, sense capes de transpilació addicionals. Per a equips que ja treballen al núvol amb AWS o Azure, aquesta homogeneïtzació simplifica els pipelines de CI/CD. A Q2BSTUDIO, en implementar solucions cloud AWS i Azure, valorem que el framework no afegeixi friccions innecessàries al desplegament.
Validació de paràmetres: esquemes estàndard vs. proveïdors de fàbrica NestJS 12.0 introdueix suport natiu per a Standard Schema, permetent utilitzar Zod, Valibot o ArkType directament en decoradors de ruta. Això redueix la dependència de class-validator i class-transformer, i ofereix inferència de tipus potent. El codi es torna més declaratiu: @Body(createUserSchema) body. Ditsmod, en canvi, opta per un enfocament injectable pur. No té pipes com a entitats separades; la validació es realitza mitjançant Factory Providers que injecten l'esquema com a segon argument de @inject(). Així, el desenvolupador construeix canonades personalitzades sense esperar que el framework oficialitzi noves llibreries. Aquest disseny encaixa perfectament amb projectes que requereixen regles de validació dinàmiques, típiques en sistemes de BI o agents IA. Per exemple, un endpoint que valida dades transformades per Power BI abans d'alimentar models predictius es beneficia d'aquest control granular. A més, Ditsmod permet combinar ciberseguretat (sanitització d'inputs) amb la lògica del domini sense afegir decoradors màgics.
Execució de peticions: interceptors RxJS vs. pipeline estricte NestJS organitza el cicle de vida en Middleware, Guards, Interceptors, Pipes i Controllers, utilitzant RxJS per manipular fluxos asíncrons. Els interceptors es vinculen amb @UseInterceptors() i poden modificar la resposta a través de next.handle(). És un model flexible però de vegades opac quan l'ordre d'execució es torna crític. Ditsmod, per contra, posseeix un pipeline administrat per RequestDispatcherExtension, amb etapes ben definides: HttpFrontend, GuardedInterceptor, interceptors personalitzats i HttpBackend. No utilitza RxJS; cada interceptor implementa una interfície HttpInterceptor amb un mètode async. Els interceptors es declaren directament al quart argument de @route(). A més, Ditsmod permet sobrescriure el RequestDispatcher complet a nivell d'aplicació si es necessita embolicar tota la petició, inclosos els guards. Aquesta rigidesa dona una predictibilitat que agraeixen equips que treballen amb compliance i auditoria, com en projectes de ciberseguretat que requereixen registrar cada pas del flux.
Quin escollir per al teu proper projecte? La decisió no és binària. NestJS ofereix un ecosistema madur, amb suport Standard Schema que redueix el boilerplate i una comunitat enorme. És ideal per a equips que busquen productivitat immediata i ja estan familiaritzats amb decoradors i RxJS. Ditsmod, per la seva banda, recompensa a qui valora la transparència del contenidor DI: cada peça de lògica (validació, interceptor, guard) es defineix com un proveïdor injectable, sense màgia oculta. A Q2BSTUDIO, en desenvolupar solucions amb intel·ligència artificial o agents autònoms, sovint preferim Ditsmod perquè la seva arquitectura explícita facilita la integració de pipelines de dades complexos i l'auditoria de cada transformació. Per a aplicacions de Business Intelligence amb Power BI, la validació estricta a la capa DI evita que dades corruptes arribin als panells. En qualsevol cas, ambdues eines —ja disponibles amb l'etiqueta next a npm— representen el futur del desenvolupament backend a Node.js. L'important és entendre els seus principis i alinear-los amb les necessitats del teu negoci, ja sigui que aposti per la familiaritat de NestJS o per la previsible fermesa de Ditsmod.
