In the Node.js backend development ecosystem, extensibility has become a critical factor when choosing a framework. Both NestJS and Ditsmod, inspired by Angular’s architecture, offer mechanisms to build modular and scalable applications. However, when it comes to creating complex plugins, OpenAPI generators, or integrations with cloud services like AWS or Azure, the differences become noticeable. This article delves into dynamic modules, dynamic providers, and extension groups—two approaches that share roots but diverge in execution.
NestJS, the most popular framework in the ecosystem, adopts the dynamic module pattern just as Angular does. A dynamic module is built via a static method that receives configuration at import time and returns an object with providers, exports, and the module itself. This allows convenient injection of values such as connection strings or API keys. But when we need something more complex—like scanning the entire application for custom decorators to generate Swagger documentation or dynamically adding interceptors—NestJS relies on the DiscoveryService and lifecycle hooks like OnModuleInit. This approach works, but it means the infrastructure logic runs after the DI container is fully built, limiting the ability to mutate the dependency tree. In enterprise applications that integrate artificial intelligence or AI agents, this limitation can lead to scattered code that is hard to maintain.
On the other hand, Ditsmod v3.0 introduces an extension system that operates in a pre-bootstrap phase, similar to compile time. Extensions implement up to three sequential hooks: stage1, stage2, and stage3. In stage1, which runs while provider arrays are still being assembled, the extension can read module metadata and on the fly insert new providers into the appropriate layers (providersPerApp, providersPerMod, providersPerRou, providersPerReq). This allows, for example, an OpenAPI generator to automatically add a validation interceptor to a specific route without needing to scan after startup. The real innovation is the extension groups: multiple independent extensions can join a group led by a main extension, sharing a common interface contract. Thus, when the lead extension requests stage1 data from the extension manager, it receives an aggregated payload with contributions from all members. This mechanism eliminates the need for a global DiscoveryService and enables building collaborative infrastructure—such as dynamic routing, security metadata, or cybersecurity logic—in a decoupled manner.
In the context of Q2BSTUDIO, a company dedicated to custom software development, these technical decisions directly impact the quality of the final product. When we work with clients requiring cloud integrations on AWS or Azure, Business Intelligence solutions with Power BI, or automation systems powered by AI agents, the ability to extend the framework without breaking the architecture is essential. With NestJS, achieving deep customization often means sacrificing code cleanliness or resorting to patches. With Ditsmod, on the other hand, extension groups allow each functionality—from a cybersecurity module to a data pipeline for BI—to integrate as an independent plugin that collaborates with others under the same contract.
To illustrate, imagine a typical SaaS platform scenario: we need to register audit metadata on every route, generate automatic OpenAPI documentation, and validate input data with a custom schema. In NestJS, we would create a global guard, an interceptor, and a route decorator, then coordinate them via DiscoveryService in OnModuleInit. In Ditsmod, we can define a main extension 'AuditRouteExtension' that in stage1 collects decorators from each module and, if it detects an audit decorator, inserts an interceptor provider into providersPerRou. Another extension, 'OpenApiExtension', joins the main extension’s group and in the same stage1 adds route metadata to a shared array. Finally, the extension manager delivers a unified payload that the main extension can consume to generate documentation or enable auditing. All this happens before the application handles the first request, ensuring a clean and predictable startup.
From a business perspective, the choice between NestJS and Ditsmod is not trivial. If your team already has experience with NestJS and the extensibility needs are basic (configuration injection, simple dynamic modules), NestJS remains a solid option with a huge community. But if you aim for modular applications where third parties can contribute features without breaking the core, or if you need deep integration with AI, cybersecurity, or BI systems, Ditsmod’s extension system provides a more solid foundation. At Q2BSTUDIO, where we design architectures for clients seeking custom applications with high quality standards, we especially value Ditsmod’s ability to keep the DI container open during the initialization phase, allowing each module to contribute to the ecosystem without coupling.
In conclusion, both NestJS and Ditsmod inherit Angular’s elegance in handling dynamic modules and dynamic providers. However, when extensibility becomes the center of the architecture—whether to integrate AI agents, automate processes, or deploy in hybrid clouds—Ditsmod offers an additional layer of control with its extension groups. The final choice will depend on the complexity of your project and your team’s maturity. But understanding these differences is key to building software that evolves painlessly.
