DEV Community: Костя Третяк

Application Lifecycle and Graceful Shutdown

Костя Третяк — Sun, 26 Jul 2026 17:49:33 +0000

Welcome to Part 5—the grand finale of our "NestJS v12.0 vs. Holu v0.1" series!

Over the last four articles, we have unpacked the strict Dependency Injection hierarchies, Native ESM migrations, compile-time Extension Groups, and powerful Metadata Reflection APIs of these two enterprise Node.js frameworks.

But building a robust enterprise application isn't just about how it starts up or how it handles requests. In the modern cloud-native world of Kubernetes, Docker, and autoscaling groups, how your application shuts down is just as critical as how it runs. When a container orchestrator sends a SIGTERM signal, your app needs to stop accepting new requests, finish processing active ones, and safely close database connections to prevent data corruption.

Today, we are exploring the Application Lifecycle and Graceful Shutdown mechanics of NestJS and Holu.

1. NestJS: The Classic Lifecycle Hooks

NestJS provides a robust, well-documented lifecycle interface. To handle startup, you use OnModuleInit and OnApplicationBootstrap.

For graceful shutdown, NestJS requires you to explicitly opt-in by calling app.enableShutdownHooks() in your main.ts. Once enabled, NestJS listens for system signals (like SIGINT or SIGTERM) and executes three shutdown phases:

OnModuleDestroy: Called after the shutdown signal is received.
BeforeApplicationShutdown: Called before connections are closed (useful for draining custom event loops).
OnApplicationShutdown: The final hook where you close database pools or Redis clients.

NestJS traverses the DI container and executes these hooks for all registered providers. However, developers must be careful: if a shutdown hook throws an unhandled error, or if you don't properly manage in-flight HTTP connections, the process might hang or drop requests abruptly.

2. Holu v0.1: The Three-Step Shutdown Sequence

Holu also requires you to activate signal interception explicitly by calling app.enableShutdownHooks() on the application instance. By default, it intercepts SIGTERM, SIGINT, SIGHUP, SIGUSR2, and SIGQUIT.

When app.close(signal) is triggered, Holu’s BaseApplication executes a strictly defined 3-step sequence:

Step 1: `BeforeShutdown` Hooks

Holu first invokes beforeShutdown() on all relevant singleton services. This phase is ideal for stopping background timers or queue workers. For instance, Holu's @holu/schedule extension automatically implements this hook to clear pending timers, stop cron jobs, and delete intervals before the server even stops.

Step 2: `customShutdown(signal)` (Connection Draining)

This is an extension point method in BaseApplication. In a REST environment, RestApplication overrides this method to perform package-level shutdown logic.
During this phase, the HTTP server initiates closure (server.close()). It stops receiving new TCP connections and immediately destroys idle keep-alive connections. Active, in-flight HTTP requests are allowed to finish processing, waiting up to the configured shutdownTimeout (which defaults to 15,000 ms).

Step 3: `OnShutdown` Hooks

Once the HTTP server is completely closed and active requests have drained, Holu calls the onShutdown() hook on your services. This is the safest place to close database connection pools or file handles, knowing that no incoming HTTP requests will attempt to use the database during the closure.

3. The Holu Performance Nuances

While the hooks might look similar to NestJS on the surface, Holu implements several aggressive performance and safety optimizations under the hood:

Instantiated Singletons Only

In NestJS, the lifecycle system generally processes the entire provider tree.
Holu is ruthlessly efficient: shutdown hooks are invoked only on singleton instances (providersPerApp and providersPerMod) that were actually instantiated during application runtime. Uninstantiated services, or any request-scoped and route-scoped providers (providersPerReq, providersPerRou), are completely excluded from shutdown hooks. This saves execution time and prevents the framework from spinning up idle dependencies just to shut them down.

Concurrent Execution & Fault Tolerance

When shutting down a large app, you don't want a single failing Redis connection to prevent your Postgres pool from closing gracefully.
Holu executes hooks for all active instances concurrently using Promise.allSettled(). Errors thrown in individual beforeShutdown or onShutdown hooks are safely caught, logged via SystemLogMediator, and do not interrupt other services' shutdown hooks.

Conclusion of the Series

As we conclude this 5-part deep dive into NestJS v12.0 and Holu v0.1, the philosophical differences between the two frameworks are crystal clear:

NestJS v12.0 remains the undisputed king of ecosystem maturity and developer convenience. With its full Native ESM migration, standard schema (Zod/Valibot) routing support, and vast array of off-the-shelf modules, it is the safest bet for most teams.
Holu v0.1 is an architectural purist’s dream. By enforcing an incredibly strict Dependency Injection hierarchy, eliminating silent collisions, validating parameters via core FactoryProviders, merging metadata via a deeply integrated Reflector (with ParentParams inheritance!), and compiling infrastructure via three-stage Extension Groups, Holu removes "framework magic" and replaces it with predictable, explicit engineering.

Both frameworks are pushing the boundaries of what is possible in enterprise Node.js.

Which one will you choose for your next project? Drop a comment below, and happy coding!

Reflection APIs, Metadata, and Custom Decorators

Костя Третяк — Sun, 26 Jul 2026 15:29:39 +0000

Welcome to Part 4 of the "NestJS v12.0 vs. Holu v0.1" series! In Part 3, we explored how both frameworks handle extensibility through Dynamic Modules and Extension Groups.

Today, we are looking at the invisible glue that holds both of these Node.js frameworks together: TypeScript Decorators and Metadata Reflection.

If you use NestJS or Holu, your code is covered in decorators—@Controller(), @Injectable(), @Get(), etc. But what happens when you need to write your own custom decorators? How do these frameworks read, store, and merge that metadata under the hood?

Let's compare the traditional NestJS @SetMetadata approach with Holu's highly engineered Reflector abstraction.

1. NestJS: The `@SetMetadata` Approach

NestJS provides a straightforward, accessible API for dealing with custom metadata, built heavily around the standard reflect-metadata package.

When you want to attach custom data to a route (for example, marking a route as "public" or assigning specific roles), you use @SetMetadata() or create a custom decorator factory:

import { SetMetadata } from '@nestjs/common';

export const Roles = (...roles: string[]) => SetMetadata('roles', roles);

@Controller('admin')
export class AdminController {
  @Get('dashboard')
  @Roles('super-admin', 'manager')
  getDashboard() {
    return { status: 'secure' };
  }
}

To read this metadata later (usually inside a Guard or Interceptor), you inject the NestJS Reflector class:

import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common';
import { Reflector } from '@nestjs/core';

@Injectable()
export class RolesGuard implements CanActivate {
  constructor(private reflector: Reflector) {}

  canActivate(context: ExecutionContext): boolean {
    const roles = this.reflector.get<string[]>('roles', context.getHandler());
    if (!roles) return true;

    const request = context.switchToHttp().getRequest();
    return roles.includes(request.user.role);
  }
}

The Limitations:
This approach is simple and effective. However, it relies on basic key-value retrieval. If you have a complex OOP structure where a child controller extends a base CRUD controller, reflect-metadata (and by extension, the default NestJS reflector methods) does not automatically traverse the inheritance tree to merge metadata from the parent class down to the child. Developers often have to write manual fallback logic to check the prototype chain.

2. Holu v0.1: The Unified Reflector Abstraction

Holu takes a fundamentally different, heavily optimized approach to metadata. Instead of just wrapping reflect-metadata, Holu's Reflector provides a unified, cached, and high-level abstraction over standard reflection metadata. (It uses the lighter reflect-metadata/lite polyfill under the hood, which is loaded automatically by @holu/core).

Creating Type-Safe Decorators

Instead of raw key-value pairs, Holu provides static factory methods to generate structured decorators: Reflector.makeClassDecorator(), Reflector.makePropDecorator(), and Reflector.makeParamDecorator().

You can pass a transformer function directly into the factory to validate and format the arguments:

import { Reflector } from '@holu/core';

interface RoleOptions {
  roles: string[];
  strict?: boolean;
}

// Generates a property-level decorator and transforms its arguments
export const requireRoles = Reflector.makePropDecorator(
  (roles: string[], strict = false) => ({ roles, strict } satisfies RoleOptions)
);

class AdminController {
  @requireRoles(['super-admin', 'manager'], true)
  secureData() {}
}

Inheritance Traversal (The Killer Feature)

One of the most powerful features of Holu's Reflector is its native understanding of OOP inheritance. It automatically merges class, property, and parameter metadata from parent classes down to children.

When Holu collects metadata for a class, it builds an internal mapping of the inheritance tree, tracking exactly where each decorator originated via the decoratorChain and paramChain fields of the MergedClassPropMeta object. If you extend a base controller, the child seamlessly inherits the parent's route and parameter decorators without any manual prototype hacking.

Constructor Inheritance: The `ParentParams` Token

One of the most frustrating aspects of standard TypeScript DI (including NestJS) is constructor inheritance. If your ChildController extends a BaseCrudController that has five injected services, your ChildController must explicitly declare all five of those services in its constructor just to pass them up via super(dep1, dep2, ...). If the base class changes, every child class breaks.

Because Holu's Reflector natively understands inheritance chains, its Dependency Injection system can solve this automatically using the special ParentParams token.

When an @injectable() class extends a parent class, Holu automatically gathers the parent's required dependencies and injects them as an array into ParentParams.

import { ParentParams, injectable, inject } from '@holu/core/di';

@injectable()
class BaseController {
  constructor(private logger: Logger, private db: DbService) {}
}

@injectable()
class ChildController extends BaseController {
  constructor(
    // We inject the parent's parameters cleanly without redeclaring them!
    @inject(ParentParams) parentParams: ConstructorParameters<typeof BaseController>,
    public childSpecificService: ChildSpecificService,
  ) {
    // Spread the array into super()
    super(...parentParams);
  }
}

You can use the @inject(ParentParams) decorator for strict type safety, or use the @ts-expect-error shorthand approach. Either way, Holu completely eliminates the brittle boilerplate of passing dependencies up the prototype chain!

Decorator Grouping (`decoratorId`)

When building complex plugins, you often have multiple decorators that belong to the same logical family. Holu allows you to group them effortlessly.

When creating a decorator, you can pass a reference to a "base" decorator as the third argument (the decoratorId).

import { Reflector, DecoratorMeta } from '@holu/core';

// 1. Create a base decorator (acts as the Group ID)
export const apiGroup = Reflector.makeClassDecorator((data?: any) => data, 'apiGroup');

// 2. Create related decorators, passing `apiGroup` as the decoratorId
export const apiModel = Reflector.makeClassDecorator((data?: any) => data, 'apiModel', apiGroup);
export const apiEntity = Reflector.makeClassDecorator((data?: any) => data, 'apiEntity', apiGroup);

Later, you can extract all metadata associated with that specific group identifier, making it incredibly easy to parse large, multi-decorator structures for things like OpenAPI documentation generation.

Iterability and Caching

When you need to read an entire class at once, Holu provides Reflector.collectMeta(Cls). This returns a MergedClassMeta object which is fully iterable. You can loop through it to get property-by-property details, constructor parameters, and inheritance maps, all of which are resolved once and cached internally for maximum performance.

Conclusion

Both frameworks provide excellent tools for metadata reflection, but they are built for slightly different developer experiences:

NestJS v12.0 maintains its highly approachable @SetMetadata and Reflector.get() pattern. It is incredibly easy to learn and covers 95% of standard web application use cases perfectly.
Holu v0.1 treats metadata reflection as a core infrastructure pillar. By providing automated inheritance traversal, decorator grouping via decoratorId, and a strongly typed, iterable MergedClassMeta object, Holu completely eliminates the boilerplate required to parse complex OOP structures.

If you are building simple guards, NestJS's approach is quick and painless. But if you are building complex libraries, automated code generators, or heavily abstracted base classes, Holu’s Reflection API feels like a superpower.

In Part 5 of the series, we will wrap up by exploring Application Lifecycle and Graceful Shutdown — comparing how both frameworks safely drain HTTP connections and close database pools in production environments. Stay tuned!

Dynamic Modules, Providers, and the Power of Extension Groups

Костя Третяк — Sun, 26 Jul 2026 15:00:26 +0000

Welcome to Part 3 of the "NestJS v12.0 vs. Holu v0.1" series! In our previous articles, we explored the strict Dependency Injection hierarchies and modern validation pipelines of these two cutting-edge Node.js frameworks.

Today, we are tackling the true hallmark of an enterprise framework: Extensibility.

When building large-scale applications, you inevitably need to write reusable libraries, configurable plugins, and complex infrastructure hooks (like OpenAPI generators, custom routers, or database orchestrators). Both NestJS and Holu draw heavy inspiration from Angular's architectural playbook to solve this, but their execution diverges dramatically as application complexity scales.

Let's explore how Dynamic Modules, Dynamic Providers, and Holu’s unique Extension Groups compare.

The Shared Ancestry: Dynamic Modules & Dynamic Providers

If you have ever used Angular, you are likely familiar with the RouterModule.forRoot() pattern. This is a Dynamic Module—a module that doesn't just statically register providers, but accepts configuration at runtime to dynamically generate providers before the DI container is built.

NestJS Dynamic Modules

NestJS fully embraces this concept. You return a DynamicModule object containing providers, exports, and module from a static factory method.

import { Module, DynamicModule } from '@nestjs/common';

@Module({})
export class DatabaseModule {
  static forRoot(connectionString: string): DynamicModule {
    return {
      module: DatabaseModule,
      providers: [
        {
          provide: 'CONNECTION_STRING',
          useValue: connectionString,
        },
      ],
    };
  }
}

Holu Dynamic Modules

Holu provides the exact same architectural capability, rooted in the same Angular philosophy. Holu supports importing modules in two forms: Static Modules (a raw class reference) and Dynamic Modules (an object implementing the DynamicModule interface).

Using Dynamic Modules in Holu, configuration details, route prefixes, or custom provider overrides can be supplied directly at the import site.

import { type DynamicModule } from '@holu/core';
import { SomeService } from './some.service.js';

export class UsersModule {
  // A static helper method returning a DynamicModule
  static withConfig(path: string): DynamicModule<UsersModule> {
    return { 
      module: this, 
      path, 
      providersPerReq: [{ token: 'CUSTOM_CONFIG', useValue: { path } }] 
    };
  }
}

In both frameworks, Dynamic Modules are excellent for initializing dynamic providers (like injecting a specific API key or database configuration).

However, what happens when you need to do something more complex? What if you need to scan the entire application for specific decorators, dynamically generate routes, or aggregate metadata from ten different third-party modules to build a Swagger file?

NestJS: Lifecycle Hooks & The Discovery Service

In NestJS, complex framework extensions are typically handled using a combination of Lifecycle Hooks (OnModuleInit, OnApplicationBootstrap) and the DiscoveryService.

If you are building an OpenAPI generator in NestJS, your logic lives inside an OnApplicationBootstrap hook. You inject the DiscoveryService, iterate over every registered controller and provider, read their Reflect metadata using the Reflector, and dynamically build your schema.

While this approach works, it has limitations:

It occurs at runtime (after the DI container is fully instantiated).
You cannot easily inject new providers into the application based on what you discover.
Coordination between multiple independent plugins requires complex workarounds.

Holu v0.1: The Extension System & Groups

Holu abandons runtime lifecycle discovery for infrastructure setup. Instead, it introduces a highly structured Extension System.

Extensions operate strictly during the application initialization stage to set up infrastructure and do not participate directly in request processing. They run after static metadata is collected from decorators, but before request handlers and DI containers are fully finalized.

The Three-Stage Pipeline

Every Holu Extension can implement up to three sequential framework lifecycle hooks that are always executed in order:

stage1(isLastModule): Used to dynamically collect metadata, push new providers into the providersPerApp, providersPerMod, providersPerRou, or providersPerReq arrays, and aggregate data.
stage2(injectorPerMod): Called after stage1 finishes for ALL modules, receiving a fully prepared module-level injector.
stage3(): Used for final post-processing before the application starts.

Because stage1 executes while provider arrays are still being assembled, a Holu extension can read a module's configuration and dynamically push an interceptor directly into that specific route's providersPerReq array. You are modifying the application graph before it is sealed.

Extension Groups: The True Game Changer

The most powerful feature of Holu's extensibility is Extension Groups.

An extension group allows multiple independent extensions to contribute data under the class token of a "Lead Extension". For example, if you have a core RestRouteExtension that handles routing, other third-party extensions can hook into it simply by declaring it in their groups array:

// 1. A third-party OpenAPI extension joins the RestRouteExtension group
export const OpenApiExtensionConfig = {
  extension: OpenApiRouteExtension,
  groups: [RestRouteExtension], // Joins the group seamlessly
  export: true,
};

When an extension joins a group, it automatically inherits the group's positioning relative to other extensions in the execution graph.

Later, when the some extension asks the ExtensionManager for its stage1 data, the manager returns an aggregated payload containing data from the Lead Extension and all member extensions registered in its group.

This means extensions can share a base interface contract and collaboratively build infrastructure (like appending Swagger documentation metadata to core route metadata) without being tightly coupled or requiring a global DiscoveryService hack.

Conclusion

Both NestJS and Holu provide excellent tools for basic configurability via Angular-inspired Dynamic Modules and Dynamic Providers.

However, when building complex architectural plugins:

NestJS relies on runtime scanning via DiscoveryService and lifecycle hooks, which can be limiting if you need to mutate the DI container dynamically.
Holu solves this with a dedicated compile-time-like Extension System. By utilizing stage1 hooks and Extension Groups, Holu allows plugins to collaboratively aggregate metadata and dynamically push providers into the DI hierarchy before the application fully starts.

In Part 4 of the series, we will take a deep dive into Reflection APIs and Custom Decorators, exploring how both frameworks handle metadata merging and inheritance. Stay tuned!

ESM Migration, Validation, and Request Execution

Костя Третяк — Sun, 26 Jul 2026 14:30:21 +0000

Welcome to Part 2 of the "NestJS v12.0 vs. Holu v0.1" series! If you missed Part 1, we covered the foundational differences in how these two frameworks handle Modules, Dependency Injection (DI) hierarchies, and Application Extensions.

Right now, both frameworks are in active development for their next major leaps and can be downloaded from npm using the next tag. This is an exciting time for Node.js developers because the ecosystem is undergoing a massive architectural shift.

In this article, we will dive into the code. We'll explore how NestJS v12.0 is modernizing its stack with native ESM and Standard Schema support, and compare that with Holu v0.1’s highly strict, DI-integrated approach to parameter validation and route interception.

1. The Native ESM Era Has Arrived

For years, developers have been trapped in the CommonJS (CJS) vs ECMAScript Modules (ESM) limbo.

NestJS v12.0 is finally slamming the door on that friction. The upcoming v12 release brings a massive full migration to Native ESM across all official packages. Thanks to Node.js's new require(esm) support, the transition is smoother than ever.

But the NestJS team didn't stop there. They are completely modernizing the default toolchain:

Vitest replaces Jest.
oxlint replaces ESLint.
Rspack replaces Webpack.

Holu v0.1, on the other hand, was built with modern ECMAScript standards and top-level await in mind from the beginning. Holu applications natively leverage ESM for bootstrapping (like await RestApplication.create(AppModule)). When it comes to testing, Holu easily integrates with Vitest, requiring only that reflect-metadata/lite is loaded early in the test setup.

Both frameworks now ensure that your entire stack—from frontend to backend in a monorepo—can finally run seamlessly on a single, native module language without redundant compilation layers.

2. Parameter Validation: Standard Schema vs. Factory Providers

When a request comes in, you need to validate the payload and extract parameters. Here, the two frameworks take wildly different philosophies.

NestJS v12.0: Standard Schema Integration

NestJS 12 introduces a highly anticipated feature: native Standard Schema support. You no longer need to rely heavily on the decorator-heavy class-validator and class-transformer packages.

Instead, NestJS v12 allows you to pass schemas from modern validation libraries like Zod, Valibot, or ArkType directly into your route decorators:

import { Controller, Post, Body } from '@nestjs/common';
import { z } from 'zod';

const createUserSchema = z.object({
  email: z.email(),
  age: z.number().min(18),
});

@Controller('users')
export class UsersController {
  @Post()
  create(@Body(createUserSchema) body: z.infer<typeof createUserSchema>) {
    return `User ${body.email} created!`;
  }
}

This reduces metadata overhead and gives developers immediate access to the rich type inference of modern schema libraries.

Holu v0.1: Parameter Validation via DI Pipes

Holu does not use separate conceptual entities like "Pipes" for validation. Instead, it handles parameter validation and transformation strictly through its Dependency Injection System, using custom FactoryProvider logic.

When you inject a parameter in Holu, you can pass contextual data directly to the injection token via the second argument of @inject(Dependency, 'input-data'). The DI injector skips caching for this dependency and executes the factory method afresh for each injection site, passing that second argument to the @input decorator inside the factory.

Here is how you build an equivalent Zod validation pipe for the request body in Holu:

import { injectable, factoryMethod, inject, ctx, input, AnyObj } from '@holu/core';
import { controller, route } from '@holu/rest';
import { HTTP_BODY } from '@holu/body-parser';
import { z } from 'zod';

const createUserSchema = z.object({
  email: z.email(),
  age: z.number().min(18),
});

// 1. Create a generic Zod Factory Provider
@injectable()
export class ZodBodyPipe {
  @factoryMethod()
  transform(@ctx(HTTP_BODY) body: AnyObj, @input schema: z.ZodSchema) {
    // Assuming the body is parsed by @holu/body-parser and attached to body
    const result = schema.safeParse(body);

    if (!result.success) {
      // In a real app, you would throw a specific HTTP error (e.g., BadRequestError)
      throw new Error(`Validation failed: ${result.error.message}`);
    }

    return result.data;
  }
}

// 2. Inject it into the Controller Method
@controller()
export class UsersController {
  @route('POST', 'users')
  create(
    // We pass the Zod schema as the second argument to @inject.
    // Holu dynamically feeds it into the @input parameter of ZodBodyPipe!
    @inject(ZodBodyPipe, createUserSchema) body: z.infer<typeof createUserSchema>
  ) {
    return `User ${body.email} created!`;
  }
}

The difference:

In the NestJS ecosystem, native Standard Schema support is a major framework-level feature that developers have been waiting for the core team to ship in v12.

Holu, on the other hand, shifts this power directly to the developer right now. Because Holu handles validation entirely through its standard Dependency Injection system via FactoryProvider mechanics, you don't need to wait for official framework integrations or special decorators to support new schema libraries. You have the flexibility to easily write these custom, deeply integrated pipes yourself using the core DI tools already provided.

3. Interceptors and Request Execution

NestJS Interceptors

In NestJS, the lifecycle is broadly: Middleware -> Guards -> Interceptors -> Pipes -> Controllers.
You bind an interceptor using the @UseInterceptors() decorator. Inside, you manipulate the RxJS stream using next.handle().

Holu's Strict RequestDispatcher Pipeline

Holu (@holu/rest) has a strict, highly optimized, non-RxJS interceptor chain managed by the RequestDispatcherExtension:

HttpFrontend: Parses path/query parameters into RequestContext and formats the final response.
GuardedInterceptor: Executes CanActivate guards. (If a guard fails, execution stops and throws a CustomError).
Custom `HTTP_INTERCEPTORS`: Your custom logic.
HttpBackend: Invokes the controller method.

Adding Route-Level Interceptors in Holu:
Instead of a separate decorator, Holu allows you to pass an array of interceptors directly into the 4th argument of the @route() decorator.

import { controller, route, HttpInterceptor, HttpHandler, RequestContext } from '@holu/rest';

export class LoggingInterceptor implements HttpInterceptor {
  async intercept(next: HttpHandler, ctx: RequestContext) {
    console.log(`[${ctx.rawReq.method}] ${ctx.rawReq.url}`);
    return next.handle();
  }
}

@controller()
export class DashboardController {
  // Signature: @route(method, path, guards, interceptors)
  @route('GET', 'dashboard/stats', [], [LoggingInterceptor]) 
  getStats() {
    return { visitors: 1024 };
  }
}

During bootstrap (stage1), the Holu InterceptorExtension automatically extracts these interceptors and registers them into the HTTP_INTERCEPTORS multi-provider array at the providersPerRou or providersPerReq level.

(Crucial Note: If you need to trace or wrap the ENTIRE request lifecycle—including Guard execution—in Holu, you don't use standard interceptors. You override the entire RequestDispatcher at the providersPerApp level).

Conclusion

Both NestJS v12.0 and Holu v0.1 (available now under the next npm tags) represent the bleeding edge of Node.js enterprise frameworks.

NestJS 12.0 brings a massive quality-of-life improvement with Native ESM, Rspack/Vitest tooling, and Standard Schema route validation, shedding years of CommonJS and class-validator legacy overhead.
Holu 3.0 continues to refine its radically explicit architecture, proving that you don't need magic—you just need a meticulously designed Dependency Injection hierarchy. By handling everything from parameter validation (via Factory Providers) to route interception within the boundaries of DI, Holu offers unmatched predictability.

Which architectural philosophy do you prefer? The familiar, schema-friendly ecosystem of NestJS, or the strict, DI-centric predictability of Holu?

Let me know in the comments below! If you haven't yet, run npm i @nestjs/core@next or npm i @holu/core@next and try them out for yourself.

A Deep Dive into Node.js Framework Architectures

Костя Третяк — Sun, 26 Jul 2026 12:56:36 +0000

If you are building enterprise-grade Node.js applications with TypeScript, chances are you are already deeply familiar with NestJS. It has become the de-facto standard for opinionated, heavily structured, Angular-inspired backend development.

But the ecosystem is always evolving, and a formidable contender has entered the arena: Holu.

Like NestJS, Holu relies on decorators, Dependency Injection (DI), and a modular architecture. However, under the hood, it takes a noticeably different, highly explicit approach to provider scoping, extension initialization, and request lifecycles.

In this first article of the "NestJS vs. Holu" series, we will explore the foundational architectural differences between the two frameworks.

1. Modules and explicit architecture

Both frameworks organize code into logical, reusable blocks called Modules.

In NestJS, you use the @Module() decorator to declare imports, controllers, providers, and exports.

Holu splits this responsibility into specialized roles, making the application graph highly explicit:

@rootModule (usually AppModule) is the single entry point.
@featureModule encapsulates reusable providers.
Specialized module decorators like @restModule or @trpcModule add transport-specific capabilities (like controllers and route appends).

Collision Resolution

One of the most distinct architectural choices in Holu is how it handles token collisions. If you import two modules in NestJS that export the same provider token, the framework resolves it silently based on import order.

Holu explicitly rejects this ambiguity. If a collision occurs, Holu throws an error and forces you to resolve it manually using arrays like resolvedCollisionsPer*. This strictness prevents hard-to-debug DI overrides in massive codebases.

2. Dependency Injection (DI) Hierarchies

NestJS handles provider scope using the Scope enum (DEFAULT, REQUEST, TRANSIENT). A Request-scoped provider in NestJS bubbles up, causing any service that injects it to also become Request-scoped, which can sometimes lead to performance bottlenecks.

Holu approaches DI through a strict Injector Hierarchy. There are four distinct levels of injectors:

providersPerApp (Application singleton)
providersPerMod (Module singleton)
providersPerRou (Route singleton)
providersPerReq (HTTP request instance)

The rule is simple but powerful: Child injectors look up to parents, but parents never look down. If a service is registered in providersPerApp, it cannot inject a service from providersPerReq. Furthermore, if you override a provider at the Req level, it shadows the parent provider without affecting the App or Mod levels.

3. Extending the Framework: Lifecycle vs. Extensions

To hook into the framework setup, NestJS provides lifecycle interfaces: OnModuleInit, OnApplicationBootstrap, etc.

Holu completely redesigns this concept with its Extensions System. In Holu, extensions are isolated infrastructure hooks that run after metadata collection but before the request handlers are created.

Instead of simple lifecycle hooks, Holu extensions implement up to three sequential stages:

stage1(isLastModule): Used to dynamically collect metadata, build routes, and push providers into arrays dynamically.
stage2(injectorPerMod): Runs after stage1 completes for all modules, receiving a fully formed module-level injector.
stage3(): Final post-processing.

Furthermore, Holu extensions can form Groups. Multiple extensions can contribute data to a single "Lead Extension," allowing plugins (like OpenAPI generators or custom body parsers) to seamlessly weave into the routing pipeline without messy workarounds.

4. The REST Request Lifecycle

In NestJS, an incoming HTTP request flows through a well-known pipeline:
Middleware -> Guards -> Interceptors -> Pipes -> Controllers -> Filters.

Holu manages HTTP requests via the @holu/rest package, executing a streamlined, nested interceptor chain managed by the RequestDispatcher. The flow is:

HttpFrontend: Parses path and query parameters.
GuardedInterceptor: Executes CanActivate guards. (If a guard fails, execution stops immediately).
Custom `HTTP_INTERCEPTORS`: User-defined or module-defined interceptors.
HttpBackend: Invokes the actual controller method.

If you need to wrap the entire request (for instance, to set up an OpenTelemetry trace that includes the Guard execution), Holu allows you to override the RequestDispatcher entirely at the providersPerApp level.

5. Task Scheduling

Both frameworks offer elegant, decorator-driven task scheduling using cron jobs, timeouts, and intervals.

In NestJS, you import the ScheduleModule and use @Cron(), @Interval(), or @Timeout().

Holu provides @holu/schedule with practically identical decorators (@cron, @interval, @timeout) and a SchedulerRegistry for runtime management. However, true to its architectural strictness, Holu enforces DI scope constraints on your scheduled tasks:
Task classes MUST be registered in providersPerMod or providersPerApp.
If you attempt to register a cron job in providersPerRou or providersPerReq, Holu will actively block it and emit a warning, preventing memory leaks and orphaned intervals that often plague request-scoped scheduling.

What's Next?

NestJS is a fantastic, battle-tested framework. However, Holu's highly explicit DI hierarchy, strict collision handling, and powerful three-stage Extension system present a compelling alternative for developers who want absolute control over their application's infrastructure and dependency graph.

In Part 2 of this series, we will dive deeper into the code. We will compare how to write custom interceptors, handle complex parameter validation (Pipes vs. Holu Factory Providers), and benchmark the request lifecycle.

Have you tried Holu yet? Let me know your thoughts on its strict DI approach in the comments!

Testing "quickie posts" on dev.to

Костя Третяк — Sat, 30 Nov 2024 10:32:32 +0000

NestJS vs. Ditsmod: pipe features

Костя Третяк ・ Oct 3

#ditsmod #nestjs #express #fastify

A quick overview of Bun's basic features and how it compares to Node.js

Костя Третяк — Wed, 28 Aug 2024 06:12:00 +0000

Bun is a JavaScript runtime, positioned by its author as a set of ready-to-use tools "out of the box" provided along with the JavaScript runtime: this includes a package manager, a bundler, and a test runner. Additionally, the author strives to offer strong TypeScript support so that there’s no need to compile TypeScript files into JavaScript files. It's been almost a year since the first version of Bun was released. In this short post, I will examine how well the claimed features align with reality and the performance it delivers.

Installing Bun

As shown on Bun's main page, on Linux or macOS, it can be installed as follows:

curl -fsSL https://bun.sh/install | bash

It can be upgraded to the next stable version with:

bun upgrade --stable

Cloning the Repository with Benchmark Code

In this article, we will use the code that can be found in my repository. Clone it, navigate to the new directory, and install dependencies:

git clone https://github.com/KostyaTretyak/bun-vs-node.git
cd bun-vs-node
bun install

Additionally, install the wrk benchmarking utility on your computer.

Comparing the Speed of Bun's Native Web Server and Node.js

Node.js on single process

First, let's see what Node.js shows, and then compare these results with Bun benchmarks. So, in the first terminal, run the node.mjs file:

node node.mjs

On my machine, the cold start takes about 5ms.

Now, in the second terminal, run the benchmark:

wrk -H 'Connection: keep-alive' --latency -d 5 -c 256 --timeout 8 -t 4 http://localhost:3000/plaintext

This command makes requests in four threads, with a concurrency of 256, for a duration of 5 seconds. On my machine, the average result is as follows:

Running 5s test @ http://localhost:3000/plaintext
  4 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    73.32ms  222.54ms   1.83s    92.72%
    Req/Sec     4.50k   665.94     6.39k    76.50%
  Latency Distribution
     50%   13.74ms
     75%   14.93ms
     90%   79.47ms
     99%    1.23s 
  89513 requests in 5.02s, 16.39MB read
Requests/sec:  17846.79
Transfer/sec:      3.27MB

So, about 17 thousand requests per second.

Node.js with cluster mode

Now let's try using the cluster mode. To do this, go back to the first terminal, stop the process by pressing Ctrl+C, and run the following:

node node-cluster.mjs

On my machine, it has 4 cores, and each process in the cluster starts twice as slowly - about 10ms on average.

Now, run the benchmark again:

wrk -H 'Connection: keep-alive' --latency -d 5 -c 256 --timeout 8 -t 4 http://localhost:3000/plaintext

This time, the results are as follows:

Running 5s test @ http://localhost:3000/plaintext
  4 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     9.03ms   18.69ms 345.62ms   97.60%
    Req/Sec     9.26k     1.55k   12.23k    83.50%
  Latency Distribution
     50%    6.42ms
     75%    8.32ms
     90%   10.85ms
     99%   85.68ms
  184883 requests in 5.03s, 33.85MB read
Requests/sec:  36720.73
Transfer/sec:      6.72MB

So, 36 thousand requests per second, which is slightly more than twice as fast compared to running on a single core without cluster mode.

Bun on single process

Now let's run the same benchmarks with Bun. Go to the first terminal, press Ctrl+C, and run:

bun bun.mjs

The process starts in about 4ms (almost as fast as in Node.js). When running the same benchmark with wrk, the following result is obtained:

Running 5s test @ http://localhost:3000/plaintext
  4 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.42ms  769.54us  26.37ms   93.00%
    Req/Sec    11.87k     0.86k   12.95k    75.00%
  Latency Distribution
     50%    5.28ms
     75%    5.80ms
     90%    6.04ms
     99%    6.77ms
  236197 requests in 5.04s, 31.99MB read
Requests/sec:  46849.13
Transfer/sec:      6.34MB

So, Bun handles 46 thousand requests per second on a single core, which is 2.5 times faster compared to Node.js.

Bun with cluster mode

Again, go to the first terminal, press Ctrl+C, and run:

bun bun-cluster.mjs

We see that in cluster mode, Bun's processes start just as quickly as without cluster mode.

Now, run the benchmark with wrk again, and the following result is obtained:

Running 5s test @ http://localhost:3000/plaintext
  4 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     3.09ms    2.08ms  32.22ms   70.02%
    Req/Sec    19.97k     1.99k   27.94k    85.50%
  Latency Distribution
     50%    2.86ms
     75%    4.16ms
     90%    5.70ms
     99%    9.41ms
  399353 requests in 5.07s, 54.08MB read
Requests/sec:  78753.89
Transfer/sec:     10.66MB

So, 78 thousand requests per second. There is a performance increase, but only about 1.5 times compared to non-cluster mode. However, this is twice as fast as Node.js in cluster mode.

Describing a summary from my benchmarking experience, I can say that these are the best results comparing "Bun vs Node.js". It seems that Bun's web server is twice (or sometimes four times) faster, but this speed does not extend to all code. As you gradually increase the amount of JavaScript code in your application, Bun's performance will quickly degrade.

And when Bun works with database code, it shows noticeably worse results compared to Node.js. As far as I understand, this happens due to the significant amount of JavaScript code in database drivers.

How Bun Works with ExpressJS

Run it with the following command:

bun express.mjs

On my machine, Bun launches this code in about 10ms, while Node.js launches it in 4ms, meaning Node.js has a 2.5 times faster cold start.

However, Bun has a special feature designed to minimize startup time. To use it, create an executable file using the following command:

bun build ./express.mjs --compile --minify --outfile mycli

It will generate a mycli file from express.mjs, which can be run as follows:

./mycli

On my machine, this file launches slightly slower (about one millisecond slower) than the uncompiled file. However, this feature is primarily intended for large projects, so no optimization for cold start is noticeable in minimal code. However, the speed of the compiled file is slightly higher.

How Bun Works with Ditsmod

If you clone the seeds from Ditsmod and install the dependencies:

git clone --depth 1 https://github.com/ditsmod/seed.git my-app
cd my-app
bun install

And try to immediately run the application using Bun:

bun run build
bun dist/main.js

It will throw the following error:

1 | (function (entry, fetcher)
    ^
SyntaxError: export 'ValueProvider' not found in './types-and-models.js'

This bug is easily fixed - just delete all tsconfig files from node_modules/@ditsmod:

rm node_modules/@ditsmod/*/tsconfig.json

That's it, now Bun works as expected:

bun dist/main.js

Summary

Personally, I don't yet see any significant advantages for switching to Bun. It has fast dependency installation, a fast web server, and possibly fast SQLite. If you open its repository, you can see that the number of bugs is overwhelming, so the Bun team has a hard time handling them.

If nothing significant happens in Bun's development over the next year, it will be unpromising for me.

@ts-stack/multer simplifies uploading files to a Node.js-based backend

Костя Третяк — Mon, 29 Jul 2024 05:17:02 +0000

This package is actually a fork of the well-known native package for ExpressJS multer v2.0.0-rc.4. It will be interesting primarily to those developers who prefer Promise-style programming instead of middleware. In addition, it is also important that this package is written in TypeScript, so the type support and context documentation in it is top notch.

Install

Make sure you have Node.js >= v20.0.6 installed. The package can be installed with the following command:

npm install @ts-stack/multer

Usage

Multer returns an object with four properties: textFields, file, files and groups. The textFields object contains the values of the text fields of the form, the file, files or groups object contains the files (as Readable stream) uploaded via the form.

The following example uses ExpressJS only for simplicity. In fact, @ts-stack/multer does not return middleware, so it is less convenient for ExpressJS than the original module. Basic usage example:

import { Multer } from '@ts-stack/multer';
import express from 'express';
import { createWriteStream } from 'node:fs';

// Here `avatar`, `photos` and `gallery` - is the names of the field in the HTML form.
const multer = new Multer({ limits: { fileSize: '10MB' } });
const parseAvatar = multer.single('avatar');
const parsePhotos = multer.array('photos', 12);
const parseGroups = multer.groups([{ name: 'avatar', maxCount: 1 }, { name: 'gallery', maxCount: 8 }]);
const app = express();

app.post('/profile', async (req, res, next) => {
  const parsedForm = await parseAvatar(req, req.headers);
  // parsedForm.file is the `avatar` file
  // parsedForm.textFields will hold the text fields, if there were any
  const path = `uploaded-files/${parsedForm.file.originalName}`;
  const writableStream = createWriteStream(path);
  parsedForm.file.stream.pipe(writableStream);
  // ...
});

app.post('/photos/upload', async (req, res, next) => {
  const parsedForm = await parsePhotos(req, req.headers);
  // parsedForm.files is array of `photos` files
  // parsedForm.textFields will contain the text fields, if there were any
  const promises: Promise<void>[] = [];
  parsedForm.files.forEach((file) => {
    const promise = new Promise<void>((resolve, reject) => {
      const path = `uploaded-files/${file.originalName}`;
      const writableStream = createWriteStream(path);
      writableStream.on('error', reject);
      writableStream.on('finish', resolve);
      file.stream.pipe(writableStream);
    });
    promises.push(promise);
  });

  await Promise.all(promises);
  // ...
});

app.post('/cool-profile', async (req, res, next) => {
  const parsedForm = await parseGroups(req, req.headers);
  // parsedForm.groups is an object (String -> Array) where fieldname is the key, and the value is array of files
  //
  // e.g.
  //  parsedForm.groups['avatar'][0] -> File
  //  parsedForm.groups['gallery'] -> Array
  //
  // parsedForm.textFields will contain the text fields, if there were any
});

In case you need to handle a text-only multipart form, you can use the .textFields() method, example:

import { Multer } from '@ts-stack/multer';
import express from 'express';

const parsetextFields = new Multer().textFields();
const app = express();

app.post('/profile', async (req, res, next) => {
  const parsedForm = await parsetextFields(req, req.headers);
  // parsedForm.textFields contains the text fields
});

Error handling

This is a list of error codes:

const errorMessages = new Map<ErrorMessageCode, string>([
  ['CLIENT_ABORTED', 'Client aborted'],
  ['LIMIT_FILE_SIZE', 'File too large'],
  ['LIMIT_FILE_COUNT', 'Too many files'],
  ['LIMIT_FIELD_KEY', 'Field name too long'],
  ['LIMIT_FIELD_VALUE', 'Field value too long'],
  ['LIMIT_FIELD_COUNT', 'Too many fields'],
  ['LIMIT_UNEXPECTED_FILE', 'Unexpected file field'],
]);

You can see these error codes in the MulterError#code property:

import { Multer, MulterError, ErrorMessageCode } from '@ts-stack/multer';

// ...
try {
  const multer = new Multer().single('avatar');
  const parsedForm = await multer(req, req.headers);
  // ...
} catch (err) {
  if (err instanceof MulterError) {
    err.code // This property is of type ErrorMessageCode.
    // ...
  }
}

The "@ts-stack/body-parser" package passes the parsing results via a Promise

Костя Третяк — Mon, 22 Jul 2024 08:13:59 +0000

The package @ts-stack/body-parser is a fork of body-parser - the native ExpressJS package. It is written in TypeScript in ESM format, without support for older versions of Node.js < v20.6.0. To install it, run the following command:

npm install @ts-stack/body-parser

This package parses the body of an HTTP request that has the following types: JSON, Raw, Text, URL-encoded. You can use it as follows:

import http from 'http';
import { getJsonParser } from '@ts-stack/body-parser';

const jsonParser = getJsonParser({ limit: '1kb' });

http.createServer(async function (req, res) {
  try {
    const body = await jsonParser(req, req.headers);
    res.statusCode = 200;
    res.setHeader('Content-Type', 'text/plain')
    res.write('you posted:\n');
    res.end(JSON.stringify(body));
  } catch (err: any) {
    // handling an error
  }
});

Alternatively, you can use the BodyParserGroup helper. It is designed for cases when you do not know which parser is needed for a specific route. When creating an instance of the BodyParserGroup class, you can pass options for the corresponding parsers, after which you can use the parse method as follows:

import { BodyParserGroup } from '@ts-stack/body-parser';

const bodyParserGroup = new BodyParserGroup({
  jsonOptions: config.jsonOptions,
  textOptions: config.textOptions,
  urlencodedOptions: config.urlencodedOptions,
  rawOptions: config.rawOptions,
});

const body = await bodyParserGroup.parse(req, req.headers, {});

Passing metadata from TypeScript code to JavaScript code using decorators for Dependency Injection

Костя Третяк — Thu, 04 Jul 2024 12:51:40 +0000

When TypeScript decorators are used for Dependency Injection, they are needed for two things. First, they signal to the TypeScript compiler that it needs to read TypeScript types, transform them into JavaScript code, and save them. Second, if additional metadata is passed to the decorator factory, it must also be stored. This may surprise many, but in the first case, decorators are not used for their intended purpose in relation to how they should be used in JavaScript code.

Configuring TypeScript projects for Dependency Injection

If you want to take advantage of TypeScript for Dependency Injection, you need to write the following in your tsconfig files:

{
  "compilerOptions": {
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true
  }
}

In addition, you need to add the reflect-metadata library as a project dependency, and also import it in the entry file (usually this file is called main.ts):

// main.ts
import "reflect-metadata";

// Your code here...

Please note that such an import must be unique for your entire project. In addition, for testing it is also necessary to make such an import if there is no main.ts import in a particular test.

Unusual use of decorators in TypeScript projects

You may be wondering why the use of decorators might be unusual. Let's look at the simplest example first without a decorator and then with a fake decorator. So, let's say you have two classes, and the second class depends on the first class:

import "reflect-metadata";

class Service1 {}

class Service2 {
  constructor(public service1: Service1) {}
}

If we run the TypeScript compiler on this file, it will output the following JavaScript code:

class Service1 {
}
class Service2 {
    service1;
    constructor(service1) {
        this.service1 = service1;
    }
}
export {};

As you can see, without decorators, the TypeScript compiler does not transfer information about what type the service1 property in Service2 should be to the JavaScript code. In this case, this information is actually lost during compilation.

Now let's add any decorator:

import "reflect-metadata";

class Service1 {}

@(fakeDecorator as any)
class Service2 {
  constructor(public service1: Service1) {}
}

function fakeDecorator() {}

This time, the TypeScript compiler will already output the following JavaScript code:

var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) {
    var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
    if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
    else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
    return c > 3 && r && Object.defineProperty(target, key, r), r;
};
var __metadata = (this && this.__metadata) || function (k, v) {
    if (typeof Reflect === "object" && typeof Reflect.metadata === "function") return Reflect.metadata(k, v);
};
class Service1 {
}
let Service2 = class Service2 {
    service1;
    constructor(service1) {
        this.service1 = service1;
    }
};
Service2 = __decorate([
    fakeDecorator,
    __metadata("design:paramtypes", [Service1])
], Service2);
function fakeDecorator() { }
export {};

As you can see, the very presence of any decorator at the class level signals the TypeScript compiler that it needs to transfer information about the constructor parameters of this class to the JavaScript code. This information is stored using the reflect-metadata library, more precisely - using the Reflect class from this library.

As you can guess, now it remains to read the stored information using the same class Reflect.

Conclusion

Therefore, if there is any decorator at the class level, the TypeScript compiler passes metadata from the TypeScript code to the JavaScript code using its own decorator, and the user-defined decorator is called dynamically within its own decorator body. Thus, you can use a function with an empty body as a decorator, but the TypeScript compiler will still transfer the metadata into the JavaScript code.

Who knows the general current statistics on dev.to?

Костя Третяк — Sun, 16 Jul 2023 11:07:41 +0000

Although I have published 10 posts on dev.to since 2021, the statistics of views of these posts are very demotivating, because they get only a few dozen views for the whole time, up to a maximum of 200. For my posts, I use such popular tags as #node, #nestjs, #typescript (and the unpopular #ditsmod tag).

In general, few articles marked with these tags are published on dev.to per day. If you believe the statistics provided by similarweb, dev.to has 12.4 million visits per month. Given that users are most active on weekdays, we can assume that dev.to has about 12400/22 ~ 560K visits per day.

Thus, all posts on dev.to have approximately 560K visits per day. Unfortunately, I don't know the number of followers to the tags I've specified. But a tag like #node should theoretically have a lot of followers.

So, why is the number of views of posts marked with popular tags so low?

DI providers collision in Ditsmod applications

Костя Третяк — Tue, 21 Feb 2023 11:35:29 +0000

During the process of importing Ditsmod modules, there may be a situation where among these modules there can be two (or more) modules that export non-identical providers with the same token. For example, a provider with the token Service1 can be exported from two modules simultaneously to the current module, in which case the developer may not know which version of the provider will be used. To avoid such ambiguity, Ditsmod throws an error.

This feature is especially useful when importing third-party modules and you don’t have the ability to control the import order. Now let’s take a closer look at when a provider collision can occur.

Imagine you have Module3 where you imported Module2 and Module1. You did this import because you need Service2 and Service1 from these modules, respectively. You are viewing how these services work, but for some reason Service1 does not work as expected. You start debug and it turns out that Service1 exports both modules: Module2 and Module1. You expected that Service1 would only be exported from Module1, but the version exported from Module2 actually worked.

To prevent this from happening, if you import two or more modules that export non-identical providers with the same token, Ditsmod will throw the following error:

Error: Importing providers to Module3 failed: exports from Module2 and Module1 causes collision with Service1. If Module3 declared in your application (it is not imported from node_modules), you should add Service1 to resolvedCollisionsPer* in this module. For example: resolvedCollisionsPerReq: [ [Service1, Module1] ].

Specifically in this case:

Module2 substitute and then exports the provider with the token Service1;
and Module1 substitute and then exports the provider with the token Service1;
providers with token Service1 are not identical in Module2 and Module1, ie from module Module2 can be exported, for example, object { token: Service1, useValue: {} }, and from Module1Service1 can be exported as a class.

And since both of these modules are imported into Module3, this causes a "provider collisions", because the developer may not know which of these substitutions will work in Module3.

Collision resolution

If Module3 is declared in your application (it is not imported from node_modules), the collision is resolved by adding to resolvedCollisionsPer* an array of two elements, with the provider's token in the first place and the module from which the provider needs to be taken in the second place:

import { Module1, Service1 } from './module1';
import { Module2 } from './module2';

@featureModule({
  imports: [Module2, Module1],
  resolvedCollisionsPerReq: [ [Service1, Module1] ]
})
export class Module3 {}

If you have installed Module3 using packages manager (npm, yarn, etc.), there is no point in modifying this module locally to resolve the collision.

This situation can only occur if Module2 and Module1 are exported from the root module, so you need to remove one of these modules from there. And, of course, after that you will have to explicitly import another module into those modules where it is needed.

DEV Community: Костя Третяк

Application Lifecycle and Graceful Shutdown

1. NestJS: The Classic Lifecycle Hooks

2. Holu v0.1: The Three-Step Shutdown Sequence

Step 1: BeforeShutdown Hooks

Step 2: customShutdown(signal) (Connection Draining)

Step 3: OnShutdown Hooks

3. The Holu Performance Nuances

Instantiated Singletons Only

Concurrent Execution & Fault Tolerance

Conclusion of the Series

Reflection APIs, Metadata, and Custom Decorators

1. NestJS: The @SetMetadata Approach

2. Holu v0.1: The Unified Reflector Abstraction

Creating Type-Safe Decorators

Inheritance Traversal (The Killer Feature)

Constructor Inheritance: The ParentParams Token

Decorator Grouping (decoratorId)

Iterability and Caching

Conclusion

Dynamic Modules, Providers, and the Power of Extension Groups

The Shared Ancestry: Dynamic Modules & Dynamic Providers

NestJS Dynamic Modules

Holu Dynamic Modules

NestJS: Lifecycle Hooks & The Discovery Service

Holu v0.1: The Extension System & Groups

The Three-Stage Pipeline

Extension Groups: The True Game Changer

Conclusion

ESM Migration, Validation, and Request Execution

1. The Native ESM Era Has Arrived

2. Parameter Validation: Standard Schema vs. Factory Providers

NestJS v12.0: Standard Schema Integration

Holu v0.1: Parameter Validation via DI Pipes

3. Interceptors and Request Execution

NestJS Interceptors

Holu's Strict RequestDispatcher Pipeline

Conclusion

A Deep Dive into Node.js Framework Architectures

1. Modules and explicit architecture

Collision Resolution

2. Dependency Injection (DI) Hierarchies

3. Extending the Framework: Lifecycle vs. Extensions

4. The REST Request Lifecycle

5. Task Scheduling

What's Next?

Testing "quickie posts" on dev.to

NestJS vs. Ditsmod: pipe features

Костя Третяк ・ Oct 3

A quick overview of Bun's basic features and how it compares to Node.js

Installing Bun

Cloning the Repository with Benchmark Code

Comparing the Speed of Bun's Native Web Server and Node.js

Node.js on single process

Node.js with cluster mode

Bun on single process

Bun with cluster mode

How Bun Works with ExpressJS

How Bun Works with Ditsmod

Summary

@ts-stack/multer simplifies uploading files to a Node.js-based backend

Install

Usage

Error handling

The "@ts-stack/body-parser" package passes the parsing results via a Promise

Passing metadata from TypeScript code to JavaScript code using decorators for Dependency Injection

Configuring TypeScript projects for Dependency Injection

Unusual use of decorators in TypeScript projects

Conclusion

Who knows the general current statistics on dev.to?

DI providers collision in Ditsmod applications

Collision resolution

Step 1: `BeforeShutdown` Hooks

Step 2: `customShutdown(signal)` (Connection Draining)

Step 3: `OnShutdown` Hooks

1. NestJS: The `@SetMetadata` Approach

Constructor Inheritance: The `ParentParams` Token

Decorator Grouping (`decoratorId`)