CLI Workflow

The NestForge CLI currently groups its workflow into five areas:

• new for scaffolding a fresh app
• g or generate for adding code to an existing app
• db for migration-oriented database workflows
• export-docs or docs for OpenAPI export
• fmt for project formatting

Scaffold a new app

Base syntax:

nestforge new <app-name>
nestforge new <app-name> --transport <http|graphql|grpc|microservices|websockets>
nestforge new <app-name> --openapi

What the transport flag changes:

• http: classic controller-first application
• graphql: schema-first bootstrap with GraphiQL support
• grpc: tonic-oriented transport setup with proto/ and build.rs
• microservices: pattern registry plus in-process client example
• websockets: gateway-first bootstrap and src/ws/

The default HTTP scaffold now keeps the bootstrap files at the root of src/ and uses .with_global_prefix("api") and .with_version("v1") in src/main.rs.

Generate application code

Generators are designed to work inside an application folder containing Cargo.toml and src/.

Core generators:

nestforge g module users
nestforge g resource users --module users
nestforge g controller users
nestforge g service users

Cross-cutting generators:

nestforge g guard auth
nestforge g decorator correlation_id
nestforge g filter rewrite_bad_request
nestforge g middleware audit
nestforge g interceptor logging
nestforge g serializer user

Transport-specific generators:

nestforge g graphql users
nestforge g grpc billing
nestforge g gateway events
nestforge g microservice users

Target a feature module

To generate inside a feature boundary instead of at the app root:

nestforge g resource users --module users

The CLI will:

• verify the feature module exists
• write DTO, service, and controller files under src/users/
• patch the module exports, providers, and controller wiring

Flat and nested layouts

The resource generator supports both nested and flat module layouts.

Use the default nested layout:

nestforge g resource users --module users

Or generate a flat layout:

nestforge g resource users --module users --flat

The flat layout keeps generated files together in the feature root instead of placing them in controllers/, services/, and dto/.

DTO prompting

When nestforge g resource runs in an interactive terminal, the CLI can prompt for DTO fields so the generated Create*Dto, Update*Dto, and entity DTO match your domain.

nestforge g resource users --module users --flat
nestforge g resource users --module users --flat --no-prompt

Use --no-prompt when you want the generator to skip the DTO field prompt and fall back to the default field set.

Database commands

The CLI includes a lightweight migration workflow.

nestforge db init
nestforge db generate create_users_table
nestforge db migrate
nestforge db status

Behavior to know:

• init creates migrations/ and .nestforge/applied_migrations.txt
• generate creates a timestamped SQL file
• migrate reads DATABASE_URL and applies pending files
• status compares migration files with recorded state and reports drift

If you want the full SQL application path around those commands, continue with:

• Database Setup
• SQL Database Workflow

Utility commands

nestforge export-docs
nestforge docs
nestforge fmt

• export-docs generates a static OpenAPI artifact from the current app
• docs is an alias for export-docs
• fmt runs cargo fmt in the app root

You can export JSON or YAML:

nestforge export-docs --format yaml --output docs/openapi.yaml

Practical advice

Use the CLI to accelerate structure, not to avoid understanding the output. After each generation step, inspect the generated code and make sure:

• module wiring is correct
• feature flags in Cargo.toml match the transport or runtime you want
• .env defaults match your local environment
• generated stubs are replaced with application-specific logic before production use