NestJS — Enterprise Node.js

Execution Context & ArgumentsHost

18 min Lesson 49 of 80

Execution Context & ArgumentsHost

NestJS applications often run across more than one transport: HTTP controllers, GraphQL resolvers, WebSocket gateways, and microservice handlers. Execution context utilities let you write guards, filters, interceptors, and decorators that understand where they are running instead of hard-coding Express request objects everywhere.

Core idea

This feature is about controlling how the application is organized and how it behaves at runtime. These are the points a developer should understand before using it in a real project:

ArgumentsHost wraps the raw handler arguments and can switch to HTTP, RPC, or WebSocket views.
ExecutionContext extends ArgumentsHost with getClass() and getHandler(), which identify the controller class and route method currently being executed.
Generic components should call getType() before reading request data so they do not accidentally break in GraphQL or microservice contexts.
Reflector metadata is normally read from context.getHandler() and context.getClass(), allowing method-level rules to override class-level defaults.
Use switchToHttp(), switchToRpc(), and switchToWs() instead of positional getArgByIndex() unless you are building a very low-level adapter.

Practical example

The following example shows the idea in a practical NestJS project. The goal is not to memorize the snippet, but to understand where it belongs in the architecture:

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

  canActivate(context: ExecutionContext): boolean {
    const roles = this.reflector.getAllAndOverride<string[]>('roles', [
      context.getHandler(),
      context.getClass(),
    ]);

    if (context.getType() === 'http') {
      const request = context.switchToHttp().getRequest();
      return this.userHasRole(request.user, roles);
    }

    if (context.getType() === 'rpc') {
      const data = context.switchToRpc().getData();
      return this.tokenHasRole(data.authToken, roles);
    }

    return true;
  }
}

Design note: ExecutionContext is the bridge between NestJS abstractions and the concrete transport. Keep reusable logic transport-aware and the same guard can support REST today and GraphQL or microservices later.

Production checklist

Prefer switchToHttp()/switchToRpc()/switchToWs() over direct array indexes.
Merge metadata from handler and class when building guards or interceptors.
Keep GraphQL-specific access behind GqlExecutionContext.create(context).
Test shared guards against at least one HTTP route and one non-HTTP context before reusing widely.

Rule of thumb: If the feature makes boundaries clearer and tests easier, it is probably the right choice. If it hides dependencies or makes tracing harder, redesign.

Summary

This lesson covers an advanced NestJS area that matters when building enterprise applications. Focus on clear boundaries, testable behavior, and choosing the right tool for the context instead of using every feature everywhere.