NestJS

Playstack NestJS packages adapt portable capabilities to dependency injection, request metadata, guards, controllers, workers, and application lifecycle. They do not move domain policy into decorators or silently register global behavior.

Start with the NestJS guide to compose authentication, account scope, and entitlements in their required request order.

Available NestJS bindings

Request-boundary order

Guard order is product behavior and remains visible in controllers or application policy:

authentication -> CSRF when cookies are ambient -> account scope
               -> entitlement or role policy -> rate limit -> handler

Authentication establishes who is calling. Account resolution revalidates which tenant they may act within. Entitlements and roles evaluate against that trusted context. Rate-limit subjects should be derived only after trustworthy identity and proxy information exist.

Module ownership

Every forRoot or forRootAsync call receives an application-configured core service or factory. Applications own database clients, queues, provider SDKs, configuration loading, global guard registration, and shutdown order. Playstack modules export their runners and consumers so worker bindings stay explicit.

Events and transactions

Decorators such as @Emits describe metadata; they cannot invent a transaction. Domain operations emit through the core event bridge inside the application transaction, and Nest lifecycle bindings pump or queue observational delivery afterward.