Node-Boot Decorators — Usage Guide

Node-Boot is built almost entirely around decorators: they are how you declare controllers, wire dependency injection, define configuration, shape HTTP responses, enable opt-in features (persistence, OpenAPI, scheduling, ...), and hook into the application lifecycle — all declaratively, without manual wiring code.

This guide documents every decorator shipped across the Node-Boot monorepo — core framework, context, DI, configuration, authorization, component scanning, and every starter package — explaining why it exists, what problem it solves, and how to use it. Sections are grouped by the package that owns the decorator, mirroring the Architecture layers described in the root README.

🧩 Core Framework (@nodeboot/core)
🧠 Application Context (@nodeboot/context)
🔌 Dependency Injection Container (@nodeboot/di)
⚙️ Configuration Properties (@nodeboot/config)
🛡️ Authorization (@nodeboot/authorization)
🔍 Component Scanning (@nodeboot/aot)
📘 OpenAPI (@nodeboot/starter-openapi)
🗄️ Persistence (@nodeboot/starter-persistence)
- Pagination
⏰ Scheduling (@nodeboot/starter-scheduler)
🌐 HTTP Clients (@nodeboot/starter-http)
✅ Validation (@nodeboot/starter-validation)
❤️ Actuator (@nodeboot/starter-actuator)
☁️ AWS (@nodeboot/starter-aws)
🎭 Backstage (@nodeboot/starter-backstage)
⚡ Supabase (@nodeboot/starter-supabase)
🔥 Firebase (@nodeboot/starter-firebase)
🤖 OpenAI (@nodeboot/starter-openai)
Further Reading

🧩 Core Framework (`@nodeboot/core`)

The decorators every Node-Boot application is built from: bootstrapping, DI markers, configuration, routing, request/response handling, middlewares, models, and lifecycle hooks.

Application Bootstrap

These decorators define the shape of the application itself: its entry point, and — as an alternative to component scanning — explicit lists of controllers, middlewares, interceptors, and configurations.

`@NodeBootApplication(options?)`

Purpose: This is the root decorator of any Node-Boot app. It exists so the framework has a single, well-known place to initialize the ApplicationContext, collect everything registered by other decorators (@Configuration/@Bean definitions, controllers, middlewares, interceptors), and prepare the IoC container bindings that the server adapter (Express, Fastify, Koa, ...) will consume when it boots. Without it, none of the other decorators would have anywhere to register themselves. It's typically combined with one or more @Enable...() decorators from starter packages to opt into features like DI, OpenAPI, persistence, validation, etc.

Example:

@EnableDI(Container)
@EnableOpenApi()
@EnableSwaggerUI()
@EnableActuator()
@EnableRepositories()
@EnableScheduling()
@EnableHttpClients()
@EnableValidations()
@EnableComponentScan()
@NodeBootApplication()
export class GreetingsApp implements NodeBootApp {
    start(): Promise<NodeBootAppView> {
        return NodeBoot.run(ExpressServer);
    }
}

`@Controllers(controllers: Function[])`

Purpose: By default, Node-Boot discovers controllers via component scanning (@EnableComponentScan). Use @Controllers when you'd rather be explicit about exactly which controller classes are part of the application — useful in tests, in serverless bundles where scanning is undesirable, or when you want the wiring to be visible in one place.

Example:

@Controllers([UserController, OrderController])
class Controllers {}

`@GlobalMiddlewares(middlewares: Function[])`

Purpose: The explicit counterpart to @Middleware-based auto-registration. Use it to declare, in one place, the full list of global middlewares an application uses — helpful for predictable ordering and for environments where scanning isn't available.

Example:

@GlobalMiddlewares([LoggingMiddleware, ErrorMiddleware])
class Middlewares {}

`@Interceptors(interceptors: Function[])`

Purpose: Same idea as @GlobalMiddlewares, but for global interceptors — classes that can inspect or transform the value returned by controller actions before it's sent as the response.

Example:

@Interceptors([AuditInterceptor])
class Interceptors {}

`@Configurations(configurationClasses: (new (...args: any[]) => any)[])`

Purpose: @Configuration classes are normally picked up automatically, but sometimes you need to force eager instantiation of a specific set of configuration classes (for example, to guarantee @Bean factories run in a controlled order, or outside of component scanning). This decorator instantiates each class in the list immediately.

Example:

@Configurations([ServerConfiguration, SecurityConfiguration])
class MultipleConfigurations {}

Dependency Injection Markers

Node-Boot's IoC container needs to know which classes it's allowed to instantiate and inject. @Component and @Service are how you opt a class into that container (the actual injection mechanics live in @nodeboot/di).

`@Component()` / `@Component(name)` / `@Component(token)` / `@Component(options)`

Purpose: Marks a class as injectable, generic infrastructure — things like clients, adapters, helpers, or cross-cutting utilities that aren't strictly "business services" but still need to be constructed and injected by the DI container. Giving it a name or token lets you resolve it later by that identifier instead of by class reference, which is useful for interface-based injection or when multiple implementations exist.

Example:

@Component()
export class GreetingComponent {
    greet(name: string) {
        return `Hello, ${name}!`;
    }
}

`@Service()` / `@Service(name)` / `@Service(token)` / `@Service(options)`

Purpose: Functionally identical to @Component (both delegate to the same DI registration mechanism), but semantically communicates that the class holds business logic — the layer between controllers and data access. Use @Service for domain/business-logic classes and @Component for lower-level building blocks; this is purely a naming convention that improves code readability.

Example:

@Service()
export class UserService {
    async findAllUser() {
        return [];
    }
}

Configuration & Beans

Node-Boot needs a way to produce objects that aren't simple @Component/@Service classes — for example, values built from external config, third-party SDK clients, or objects that depend on async initialization. @Configuration and @Bean solve exactly that, mirroring Spring's @Configuration/@Bean model.

`@Configuration(options?)`

Purpose: Marks a class as a source of bean factories. It exists to group related @Bean methods together (e.g. all server-related beans, or all security-related beans) and to support conditional loading: with onConfig, a whole configuration class can be skipped unless a given config path is present, and combined with @Profile, it can be restricted to specific environments (dev, test, prod, ...). This lets you keep environment-specific or feature-flagged wiring out of your main application code.

Example:

@Configuration()
export class ServerConfiguration {
    @Bean(SERVER_CONFIGURATIONS)
    public serverConfig({config, logger}: BeansContext) {
        logger.debug("Resolving server configuration");
        return config.getOptional("server");
    }
}

Conditional loading based on config and profile:

@Configuration({onConfig: "feature.enabled"})
@Profile(["dev", "test"])
export class DevConfig {
    @Bean()
    devBean() {
        return new DevHelper();
    }
}
// Only loaded if config.has("feature.enabled") is true AND active profile is "dev" or "test".

`@Bean(beanName?)`

Purpose: Marks a factory method inside a @Configuration class. It exists so you can construct and register objects that need custom instantiation logic — reading from config, calling an async API, wrapping a third-party client — rather than being directly decorated with @Component/@Service. The method receives a BeansContext (giving access to config, logger, etc.) and can be synchronous or asynchronous; the returned value is registered in the IoC container under the class/token, or under beanName if provided.

Example:

@Configuration()
export class AppConfig {
    @Bean()
    greeting() {
        return "Hello, World!";
    }

    @Bean("asyncService")
    async createService(ctx: BeansContext) {
        return new MyService(await ctx.config.get("serviceUrl"));
    }
}

Controllers & Routing

These decorators define your HTTP surface: which classes handle requests, and which methods respond to which routes and verbs.

`@Controller(baseRoute?, version?, options?)`

Purpose: Declares a class as an HTTP controller — the entry point that maps incoming requests to your application's logic. baseRoute lets you prefix every action's route (e.g. /users), and version prefixes it further for API versioning (e.g. /v1/users) while also recording the version as metadata (useful for OpenAPI grouping). Without @Controller, a class's @Get/@Post/etc. methods are inert — this decorator is what registers the class with the routing engine and (if a DI container is present) makes it injectable/constructible.

Example:

@Controller("/users", "v1")
export class UserController {
    constructor(private readonly user: UserService) {}

    @Get("/")
    async getUsers() {
        return this.user.findAllUser();
    }
}

HTTP Method decorators: `@Get`, `@Post`, `@Put`, `@Patch`, `@Delete`, `@Head`, `@All`, `@Method`

Purpose: Each of these marks a controller method as the handler for a specific HTTP verb on a given route, so the framework knows to invoke it when a matching request arrives. @Get/@Post/@Put/@Patch/@Delete/@Head are convenience wrappers for their respective verbs; @All matches any verb; @Method(verb, route, options) is the generic, lower-level form used when the HTTP verb itself needs to be computed dynamically (e.g. building a decorator factory).

Example:

@Controller("/users")
export class UserController {
    @Get("/:id")
    async getUserById(@Param("id") userId: number) {
        return this.user.findUserById(userId);
    }

    @Post("/")
    @HttpCode(201)
    async createUser(@Body() userData: CreateUserDto) {
        return this.user.createUser(userData);
    }

    @Put("/:id")
    async updateUser(@Param("id") userId: number, @Body() userData: UpdateUserDto) {
        return this.user.updateUser(userId, userData);
    }

    @Delete("/:id")
    async deleteUser(@Param("id") userId: number) {
        await this.user.deleteUser(userId);
    }

    @All("/ping")
    ping() {
        return {pong: true};
    }
}

Request Parameter Injection

HTTP handlers need data from the incoming request — route params, query strings, headers, body, cookies, files, and so on. Rather than manually reaching into req/ctx objects, Node-Boot lets you declare exactly what a method parameter needs, and injects it for you (with optional parsing, validation, and class-transformation). This keeps controller signatures self-documenting and framework-agnostic (the same decorators work across Express, Fastify, Koa, and native HTTP).

Decorator	Purpose (what it injects)
`@Param(name)`	A single route parameter (e.g. `:id`); always required, since the route wouldn't match otherwise
`@Params(options?)`	All route parameters at once, as an object — useful for wildcard/catch-all routes
`@QueryParam(name, options?)`	A single query string parameter (e.g. `?name=...`)
`@QueryParams(options?)`	All query string parameters as an object
`@Body(options?)`	The entire parsed request body — typically a DTO class
`@BodyParam(name, options?)`	A single field plucked out of the request body, without needing the whole DTO
`@HeaderParam(name, options?)`	A single HTTP request header
`@HeaderParams()`	All HTTP request headers as an object
`@CookieParam(name, options?)`	A single cookie value
`@CookieParams()`	All cookies as an object
`@Session(options?)`	The session object attached to the request (requires session middleware)
`@SessionParam(name, options?)`	A single property read off the session object
`@State(name?)`	A state object attached to the request by upstream middleware
`@UploadedFile(name, options?)`	A single uploaded file for a given form field
`@UploadedFiles(name, options?)`	All uploaded files under a given form field
`@Req()`	The raw, underlying request object — an escape hatch when no other decorator fits
`@Res()`	The raw, underlying response object — an escape hatch for manual response handling
`@Ctx()`	The Koa `Context` object (only meaningful on the Koa server adapter)

Example:

@Controller("/users")
export class UserController {
    @Get("/search")
    search(
        @QueryParam("name") name: string,
        @QueryParams() allQueryParams: Record<string, string>,
        @HeaderParam("x-request-id") requestId: string,
        @CookieParam("session-id") sessionId: string,
    ) {
        return this.user.search(name);
    }

    @Post("/:id/avatar")
    uploadAvatar(@Param("id") userId: number, @UploadedFile("avatar") file: Express.Multer.File) {
        return this.user.setAvatar(userId, file);
    }
}

Most of these decorators accept a common options object so you don't need extra manual parsing/validation code in the handler body:

required — throw a 400 automatically if the value is missing.
parse — JSON-parse a string value before injecting it.
transform — apply class-transformer to convert the raw value into a class instance.
validate — run class-validator against the (transformed) value before invoking the handler.
type — explicitly declare the expected type, used for transformation/validation and OpenAPI schema generation.

Response Handling

Once a controller action returns a value, these decorators let you shape how that value becomes an HTTP response — status code, headers, redirects, templates — without manually touching the response object.

`@HttpCode(code)`

Purpose: Lets you set a specific success status code (e.g. 201 Created, 204 No Content) declaratively, instead of the framework's default (usually 200). The code is only applied when the action resolves successfully — if it throws, error handling takes over instead.

Example:

@Post("/")
@HttpCode(201)
createUser(@Body() userData: CreateUserDto) {
    return this.user.createUser(userData);
}

`@ContentType(contentType)`

Purpose: Explicitly sets the response's Content-Type header — useful when an action returns something other than JSON, such as CSV, plain text, or XML, and you want that reflected correctly in the response.

Example:

@Get("/report")
@ContentType("text/csv")
downloadReport() {
    return this.reports.generateCsv();
}

`@Header(name, value)`

Purpose: Sets an arbitrary, static response header. Useful for caching directives, custom headers, or any header not covered by a more specific decorator.

Example:

@Get("/")
@Header("Cache-Control", "no-store")
getUsers() {
    return this.user.findAllUser();
}

`@Location(url)`

Purpose: A focused shorthand for setting the Location header, most commonly used alongside @HttpCode(201) on creation endpoints to tell the client where the newly created resource can be found.

Example:

@Post("/")
@Location("/users")
@HttpCode(201)
createUser(@Body() userData: CreateUserDto) {
    return this.user.createUser(userData);
}

`@Redirect(url)`

Purpose: Declaratively redirects the client to another URL, so you don't have to manually call response.redirect(...) inside the handler body.

Example:

@Get("/old-path")
@Redirect("/new-path")
redirectOldPath() {}

`@Render(template)`

Purpose: For server-rendered views, this tells the framework which template to render with the object returned by the action, instead of serializing it as JSON. Requires a template engine to be configured on the underlying server adapter.

Example:

@Get("/home")
@Render("home.ejs")
home() {
    return {title: "Welcome"};
}

`@OnNull(codeOrError)` / `@OnUndefined(codeOrError)`

Purpose: Removes the need for if (result == null) throw ... boilerplate in every handler. These decorators declare, at the method level, what should happen when an action's return value is null (@OnNull) or undefined (@OnUndefined): either respond with a specific HTTP status code (e.g. 404), or throw a specific error class to be handled by your error-handling middleware.

Example:

@Get("/:id")
@OnUndefined(404)
getUserById(@Param("id") userId: number) {
    return this.user.findUserById(userId);
}

`@ResponseClassTransformOptions(options)`

Purpose: Overrides the global class-transformer options (see @EnableClassTransformer) for a single action's response — for example, to exclude extraneous fields or apply different serialization groups just for that endpoint, without changing the app-wide default.

Example:

@Get("/")
@ResponseClassTransformOptions({excludeExtraneousValues: true})
getUsers() {
    return this.user.findAllUser();
}

Middlewares & Interceptors

Cross-cutting concerns — logging, auth, error handling, auditing — shouldn't be scattered across every controller. These decorators let you register that logic once, either globally or scoped to specific controllers/actions.

`@Middleware(options)`

Purpose: Marks a class as a global middleware that runs for every request. type: "before" runs prior to the controller action (e.g. logging, auth checks); type: "after" runs after the action has produced a result (e.g. response shaping, audit logging). priority controls the order multiple middlewares run in, which matters when one middleware depends on another having run first.

Example:

@Middleware({type: "before"})
export class LoggingMiddleware implements MiddlewareInterface<Request, Response> {
    @Inject()
    private logger: Logger;

    async use(action: Action<Request, Response, Function>): Promise<void> {
        this.logger.info("Incoming request");
    }
}

`@ErrorHandler()`

Purpose: A specialized "after" middleware whose job is exclusively to catch errors thrown anywhere in the request pipeline and turn them into a proper HTTP response. Centralizing this logic means individual controllers don't need their own try/catch blocks for standard error formatting.

Example:

@ErrorHandler()
export class ErrorMiddleware implements ErrorHandlerInterface<HttpError, Request, Response> {
    @Inject()
    private logger: Logger;

    async onError(error: HttpError, action: Action<Request, Response, Function>): Promise<void> {
        const {response} = action;
        response.status(error.httpCode ?? 500).json({message: error.message});
    }
}

`@Interceptor(options?)`

Purpose: Registers a global interceptor — logic that runs after a controller action returns, with access to both the action and its result, so it can transform, wrap, or log that result before it's sent to the client. Unlike an "after" middleware, interceptors are specifically designed around the return value of the action. priority controls ordering when multiple interceptors are registered.

Example:

@Interceptor({priority: 1})
export class AuditInterceptor implements InterceptorInterface {
    intercept(action: Action, result: any) {
        return result;
    }
}

`@UseBefore(...middlewares)` / `@UseAfter(...middlewares)`

Purpose: The scoped counterpart to @Middleware. Instead of running for every request in the app, these attach one or more middlewares (classes or plain functions) to a single controller (applies to all its actions) or a single action, running before/after just that scope. Useful when a concern (like auth) only applies to part of your API.

Example:

@Controller("/users")
@UseBefore(AuthMiddleware)
export class UserController {
    @Get("/:id")
    @UseAfter(AuditMiddleware)
    getUserById(@Param("id") userId: number) {
        return this.user.findUserById(userId);
    }
}

`@UseInterceptor(...interceptors)`

Purpose: The scoped counterpart to @Interceptor. Attaches one or more interceptors (classes or inline functions) to a specific controller or action, rather than globally — handy for one-off response shaping without affecting the rest of the app.

Example:

@Get("/")
@UseInterceptor((action, result) => ({...result, cached: false}))
getUsers() {
    return this.user.findAllUser();
}

Models & Validation

These decorators describe the shape of the data flowing through your application — request/response DTOs and domain models — so that Node-Boot (and starters like OpenAPI and validation) can generate schemas, validate payloads, and transform data automatically.

📖 Validation library: Runtime validation (@IsEmail, @IsString, @IsOptional, @MinLength, @IsArray, @IsIn, ...) is not implemented by Node-Boot itself — it's powered by class-validator, applied alongside @Property() on the same field. Any built-in class-validator decorator works out of the box; see its README for the full list. Validation is only enforced on incoming data once @EnableValidations is applied to the app and validate: true is set on the relevant param decorator (@Body, @QueryParam, ...).

When a built-in rule isn't expressive enough, you can write your own custom validation decorator with class-validator's registerDecorator(...) API — it's a plain property decorator, so it composes with @Property()/@Model() exactly like a built-in one:

import {registerDecorator, ValidationArguments, ValidationOptions} from "class-validator";

export function IsValidName(validationOptions?: ValidationOptions) {
    return function (object: object, propertyName: string) {
        registerDecorator({
            name: "IsValidName",
            target: object.constructor,
            propertyName,
            options: validationOptions,
            validator: {
                validate(value: any) {
                    return typeof value === "string" && /^[a-z0-9]([a-z0-9-]{0,61}[a-z0-9])?$/.test(value);
                },
                defaultMessage() {
                    return "Value must be 1-63 lowercase alphanumeric/hyphen characters, starting/ending with a letter or digit.";
                },
            },
        });
    };
}

// Usage — combine it with @Property() like any built-in validator:
@Model()
export class CreateUserDto {
    @IsValidName()
    @Property({required: true, description: "Unique, DNS-safe resource name"})
    name: string;
}

See starters/validation's README for the full walk-through, including how custom validators interact with app-config.yaml validation options.

`@Model(bindings?)`

Purpose: Marks a class as a first-class Node-Boot model. It exists so tooling (OpenAPI schema generation, (de)serialization) can recognize the class as a data shape worth documenting/transforming, rather than an arbitrary class. bindings lets you map generic property names to concrete types, useful for models with generic-like fields.

ℹ️ @nodeboot/starter-openapi exports its own @Model that behaves identically but is additionally responsible for wiring the class into OpenAPI schema generation — import it from @nodeboot/starter-openapi when using OpenAPI.

Example:

@Model()
export class UserModel {
    @Property({description: "User ID"})
    id: string;

    @Property({description: "User email address"})
    @IsEmail()
    email: string;
}

`@Property(options?)`

Purpose: Marks an individual field of a @Model class as a documented model property. It exists because plain TypeScript types are erased at runtime — @Property captures the field's design-time type plus extra metadata (name, required, description, explicit type) so it can be used for OpenAPI schema generation and runtime validation/transformation, working alongside class-validator decorators like @IsEmail()/@IsString().

Example:

@Model()
export class CreateUserDto {
    @Property({description: "User email address"})
    @IsEmail()
    email: string;

    @Property({description: "User name", required: false})
    @IsString()
    @IsOptional()
    name?: string;
}

`@EnableClassTransformer(options?)` / `@ClassToPlainTransform(options)` / `@PlainToClassTransform(options)`

Purpose: Controls whether and how class-transformer is applied application-wide when converting between plain request/response payloads and class instances. @EnableClassTransformer turns this behavior on (and can set both directions' options at once); @ClassToPlainTransform/@PlainToClassTransform let you fine-tune the ClassTransformOptions used specifically for outgoing (classToPlain) or incoming (plainToClass) conversions, independently of each other.

Example:

@EnableClassTransformer({enabled: true})
class Transformation {}

Lifecycle Hooks

`@PostConstruct()`

Purpose: Constructor injection alone isn't always enough — sometimes initialization logic needs to run after all dependencies have been injected (e.g. warming a cache, opening a connection using an injected config service). @PostConstruct marks a method to be invoked automatically right after the DI container finishes constructing and wiring an instance, so that setup logic doesn't have to live awkwardly inside the constructor.

Example:

@Service()
export class CacheWarmer {
    @Inject()
    private cache: CacheService;

    @PostConstruct()
    async init() {
        await this.cache.warmUp();
    }
}

📖 Full documentation: @nodeboot/core README

Endpoint	Enabled by	Description
`GET /api-docs/swagger.json`	`@EnableOpenApi()`	The generated OpenAPI 3 spec, as JSON.
`GET /api-docs`	`@EnableSwaggerUI()`	Interactive Swagger UI, rendered from the spec above.

Parent class	Source	Backing store	Adds
`Repository<T>`	TypeORM	SQL (Postgres, MySQL, SQLite, ...)	Standard TypeORM repository API (`find`, `save`, `createQueryBuilder`, ...).
`MongoRepository<T>`	TypeORM	MongoDB	Standard TypeORM Mongo repository API, plus native MongoDB query operators.
`TreeRepository<T>`	TypeORM	SQL	Tree-structure operations (`findTrees`, `findAncestors`, `findDescendants`, ...) for adjacency-list/closure-table entities.
`PagingAndSortingRepository<T>`	`@nodeboot/starter-persistence`	SQL	Everything `Repository<T>` has, plus `findPaginated(...)` (offset-based) and `findCursorPaginated(...)` (cursor-based) — see Pagination below.
`MongoPagingAndSortingRepository<T>`	`@nodeboot/starter-persistence`	MongoDB	Everything `MongoRepository<T>` has, plus `findById(...)`, `findPaginated(...)`, and `findCursorPaginated(...)` — see Pagination below.

Endpoint	Description
`GET /actuator`	Lists all available actuator endpoints.
`GET /actuator/info`	Runtime info: hostname, Node version, load average, uptime, active profiles, build info.
`GET /actuator/git`	Git branch/commit metadata, read from a `git.properties` file.
`GET /actuator/config`	The fully resolved application configuration (⚠️ sensitive — see the package README's security note).
`GET /actuator/memory`	Memory diagnostics: `os.freemem/totalmem`, `process.memoryUsage()`, V8 heap statistics.
`GET /actuator/metrics`	All registered Prometheus metrics, as JSON.
`GET /actuator/prometheus`	All registered Prometheus metrics, in Prometheus text exposition format.
`GET /actuator/controllers`	Introspection of all registered Node-Boot controllers, routes, and actions.
`GET /actuator/interceptors`	Introspection of all registered interceptors.
`GET /actuator/middlewares`	Introspection of all registered middlewares.
`GET /actuator/health`	Combined readiness + liveness payload, plus links to the individual endpoints below.
`GET /actuator/health/readiness`	`200` once the app (and persistence layer, if enabled) has finished starting; `503` otherwise.
`GET /actuator/health/liveness`	Always `200 {"status": "ok"}` while the process is running — suitable for basic liveness probes.

Sample Project	Deployment Type	Description	Key Features
sample-express	HTTP Server	Flagship Express reference app with full-stack features	Express, SQLite/TypeORM, OpenAPI, validation, authorization, scheduling, actuator, migrations
sample-express-mongodb	HTTP Server	Express with MongoDB & Firebase integration	Express, MongoDB, Firebase, paging/cursor pagination, schemaless persistence
sample-fastify	HTTP Server	High-performance Fastify server	Fastify adapter, OpenAPI, fast routing
sample-koa	HTTP Server	Lightweight Koa server	Koa adapter, middleware composition
sample-native-http	HTTP Server	Pure Node.js HTTP server (no framework)	Native `http` module, minimal dependencies
sample-native-http-supabase	HTTP Server	Native HTTP with Supabase persistence	Native `http`, Supabase database, authentication
sample-lambda	Serverless	AWS Lambda function handler	Lambda adapter, API Gateway integration, stateless
sample-cloudflare	Serverless	Cloudflare Workers edge deployment	Workers runtime, edge computing, global distribution
sample-google-cloud-functions	Serverless	Google Cloud Functions	GCP Functions runtime, HTTP triggers
sample-netlify	Serverless	Netlify Functions deployment	Netlify runtime, JAMstack integration
sample-vercel	Serverless	Vercel Serverless Functions	Vercel runtime, Next.js compatible
sample-encore	Serverless	Encore.ts service	Encore platform, type-safe APIs, built-in infrastructure
sample-ghost-server	Desktop / Daemon	Background service with no HTTP layer	Persistence, scheduling, HTTP clients (as consumer), ideal for workers/daemons

Uh oh!

FilesExpand file tree

USAGE_GUIDE.md

Latest commit

History

USAGE_GUIDE.md

File metadata and controls

Node-Boot Decorators — Usage Guide

Table of Contents

🧩 Core Framework (@nodeboot/core)

Application Bootstrap

@NodeBootApplication(options?)

@Controllers(controllers: Function[])

@GlobalMiddlewares(middlewares: Function[])

@Interceptors(interceptors: Function[])

@Configurations(configurationClasses: (new (...args: any[]) => any)[])

Dependency Injection Markers

@Component() / @Component(name) / @Component(token) / @Component(options)

@Service() / @Service(name) / @Service(token) / @Service(options)

Configuration & Beans

@Configuration(options?)

@Bean(beanName?)

Controllers & Routing

@Controller(baseRoute?, version?, options?)

HTTP Method decorators: @Get, @Post, @Put, @Patch, @Delete, @Head, @All, @Method

Request Parameter Injection

Response Handling

@HttpCode(code)

@ContentType(contentType)

@Header(name, value)

@Location(url)

@Redirect(url)

@Render(template)

@OnNull(codeOrError) / @OnUndefined(codeOrError)

@ResponseClassTransformOptions(options)

Middlewares & Interceptors

@Middleware(options)

@ErrorHandler()

@Interceptor(options?)

@UseBefore(...middlewares) / @UseAfter(...middlewares)

@UseInterceptor(...interceptors)

Models & Validation

@Model(bindings?)

@Property(options?)

@EnableClassTransformer(options?) / @ClassToPlainTransform(options) / @PlainToClassTransform(options)

Lifecycle Hooks

@PostConstruct()

🧠 Application Context (@nodeboot/context)

@ShutdownHook(options?)

@Lifecycle(type)

@Profile(profiles: string[])

🔌 Dependency Injection Container (@nodeboot/di)

@EnableDI(iocContainer, options?)

@Inject() / @Inject(type) / @Inject(name) / @Inject(token)

⚙️ Configuration Properties (@nodeboot/config)

@ConfigurationProperties({configPath, configName})

🛡️ Authorization (@nodeboot/authorization)

@EnableAuthorization(currentUserCheckerClass?, authorizationCheckerClass?)

@Authorized() / @Authorized(role) / @Authorized(roles)

@CurrentUser(options?)

🔍 Component Scanning (@nodeboot/aot)

@EnableComponentScan(options?)

📘 OpenAPI (@nodeboot/starter-openapi)

@EnableOpenApi()

@EnableSwaggerUI()

@Model(bindings?) (OpenAPI variant)

@OpenAPI(spec)

@ResponseSchema(responseClass, options?)

🗄️ Persistence (@nodeboot/starter-persistence)

@EnableRepositories()

@DataRepository(entity)

@Transactional(options?)

@DatasourceConfiguration(options)

@PersistenceNamingStrategy()

@PersistenceCache()

@Migration()

@EntityEventSubscriber()

Pagination

⏰ Scheduling (@nodeboot/starter-scheduler)

@EnableScheduling()

🧩 Core Framework (`@nodeboot/core`)

`@NodeBootApplication(options?)`

`@Controllers(controllers: Function[])`

`@GlobalMiddlewares(middlewares: Function[])`

`@Interceptors(interceptors: Function[])`

`@Configurations(configurationClasses: (new (...args: any[]) => any)[])`

`@Component()` / `@Component(name)` / `@Component(token)` / `@Component(options)`

`@Service()` / `@Service(name)` / `@Service(token)` / `@Service(options)`

`@Configuration(options?)`

`@Bean(beanName?)`

`@Controller(baseRoute?, version?, options?)`

HTTP Method decorators: `@Get`, `@Post`, `@Put`, `@Patch`, `@Delete`, `@Head`, `@All`, `@Method`

`@HttpCode(code)`

`@ContentType(contentType)`

`@Header(name, value)`

`@Location(url)`

`@Redirect(url)`

`@Render(template)`

`@OnNull(codeOrError)` / `@OnUndefined(codeOrError)`

`@ResponseClassTransformOptions(options)`

`@Middleware(options)`

`@ErrorHandler()`

`@Interceptor(options?)`

`@UseBefore(...middlewares)` / `@UseAfter(...middlewares)`

`@UseInterceptor(...interceptors)`

`@Model(bindings?)`

`@Property(options?)`

`@EnableClassTransformer(options?)` / `@ClassToPlainTransform(options)` / `@PlainToClassTransform(options)`

`@PostConstruct()`

🧠 Application Context (`@nodeboot/context`)

`@ShutdownHook(options?)`

`@Lifecycle(type)`

`@Profile(profiles: string[])`

🔌 Dependency Injection Container (`@nodeboot/di`)

`@EnableDI(iocContainer, options?)`

`@Inject()` / `@Inject(type)` / `@Inject(name)` / `@Inject(token)`

⚙️ Configuration Properties (`@nodeboot/config`)

`@ConfigurationProperties({configPath, configName})`

🛡️ Authorization (`@nodeboot/authorization`)

`@EnableAuthorization(currentUserCheckerClass?, authorizationCheckerClass?)`

`@Authorized()` / `@Authorized(role)` / `@Authorized(roles)`

`@CurrentUser(options?)`

🔍 Component Scanning (`@nodeboot/aot`)

`@EnableComponentScan(options?)`

📘 OpenAPI (`@nodeboot/starter-openapi`)

`@EnableOpenApi()`

`@EnableSwaggerUI()`

`@Model(bindings?)` (OpenAPI variant)

`@OpenAPI(spec)`

`@ResponseSchema(responseClass, options?)`

🗄️ Persistence (`@nodeboot/starter-persistence`)

`@EnableRepositories()`

`@DataRepository(entity)`

`@Transactional(options?)`

`@DatasourceConfiguration(options)`

`@PersistenceNamingStrategy()`

`@PersistenceCache()`

`@Migration()`

`@EntityEventSubscriber()`

⏰ Scheduling (`@nodeboot/starter-scheduler`)

`@EnableScheduling()`

`@Scheduler(cronExpression)`

🌐 HTTP Clients (`@nodeboot/starter-http`)

`@EnableHttpClients()`

`@HttpClient(config, plugins?)`

✅ Validation (`@nodeboot/starter-validation`)

`@EnableValidations()`

❤️ Actuator (`@nodeboot/starter-actuator`)

`@EnableActuator()`

☁️ AWS (`@nodeboot/starter-aws`)

`@EnableAws()`

`@SqsListener(queueUrlOrConfigPlaceholder)`

🎭 Backstage (`@nodeboot/starter-backstage`)

`@EnableBackstage()`

⚡ Supabase (`@nodeboot/starter-supabase`)

`@EnableSupabase()`

🔥 Firebase (`@nodeboot/starter-firebase`)

`@EnableFirebase()`

🤖 OpenAI (`@nodeboot/starter-openai`)

`@EnableOpenAI()`