Production Ready NestJS Microservice Setup with Candy-Nest-CLI 🍬

If you build microservices with NestJS, you already know how powerful and structured the framework is. However, starting a new project often involves a fair amount of initial setup.

Every time a new service is spun up, developers usually have to go through similar steps:

• Setting up docker-compose.yml for local databases.


• Configuring TypeORM, Prisma, or Mongoose.


• Wiring up message brokers like Kafka or RabbitMQ.


• Dealing with local environment startup issues.


• Setting up loggers and metrics.

By the time you actually start writing business logic, a good amount of time has already gone into scaffolding.

Save your AI tokens! While you could prompt ChatGPT or Claude to write this boilerplate, generating a fully-wired NestJS microservice with infrastructure configs easily burns 3,000 to 5,000+ tokens per project (not to mention the context window eaten up by debugging configuration errors). Candy-Nest-CLI lets you bypass that entirely so you can save your usage limits for writing actual business logic.

To help automate this process, I put together Candy-Nest-CLI—an open-source interactive scaffolding tool designed to generate production-ready NestJS microservices.

🛠️ Building a Service: Step-by-Step

Let's walk through exactly how easy it is to spin up a fully-wired backend service with a PostgreSQL database and Kafka messaging queue.

Step 1: Installation & Initialization

You can either install the CLI globally to have it available anywhere, or run it directly on the fly.

Option 1: Global Installation (Recommended)

Open your terminal and install the package globally:

# Using npm

npm install -g candy-nest-cli



# Or using yarn

yarn global add candy-nest-cli

Once installed, you can generate a new project by running:

candy-nest-cli init user-service

Option 2: Using npx (No Installation)

If you prefer not to install packages globally, you can just run:

npx candy-nest-cli init user-service

Step 2: Choose Your Stack

The CLI uses @inquirer/prompts to walk you through a highly detailed setup. To build our target microservice, we will answer the prompts like this:

1. 
   What is the name of your project? user-service
   


2. 
   Which package manager do you want to use? npm
   


3. 
   Select the communication protocols to support: REST
   


4. 
   Which HTTP adapter do you want to use? Express
   


5. 
   Do you want to include a database? Yes
   


6. 
   Select databases to include: PostgreSQL (RDBMS)
   


7. 
   Which ORM for PostgreSQL? TypeORM
   


8. 
   Do you want to configure an messaging queue? Yes
   


9. 
   Which messaging queue do you want to use? Kafka
   


10. 
    Do you want to configure Dead Letter Queue (DLQ) and Retries? Yes
    


11. 
    Do you want to include Redis for caching? Yes
    


12. 
    Which logger do you want to configure? Pino
    


13. 
    Which tracing & metrics solution do you want? Prometheus
    


14. 
    Do you want to generate API documentation (Swagger)? Yes
    


15. 
    Do you want to include a Circuit Breaker (Opossum)? Yes
    

1. Package Manager Selection

Choose your preferred package manager (npm, yarn, or pnpm). We will select npm for this project.

3. HTTP Adapter Selection

Choose between Express (the industry standard) and Fastify (high performance). We'll select Express for maximum compatibility.

5. Database Choice Selection

Choose which database to use (PostgreSQL, MySQL, or MongoDB). We'll select PostgreSQL (RDBMS) for robust relational database management.

7. Messaging Queue Integration

Select whether you want to configure an event-driven messaging queue. We'll select Yes.

9. Dead Letter Queue (DLQ) & Retries

Select whether to set up robust message handling with a Dead Letter Queue (DLQ) and custom retry loops to ensure event resiliency out of the box. We'll select Yes.

11. Logger Selection

Select your logging solution (Winston, Pino, or the default NestJS logger). We'll select Pino for high-speed JSON logging.

13. API Documentation

Choose if you want fully-featured auto-generating Swagger documentation for your REST APIs. We'll select Yes.

After confirming your final choice, the CLI will output the progress as it generates the files, writes configurations, and installs the dependencies automatically.

Sensible Defaults vs. Ultimate Flexibility

candy-nest-cli is designed with sensible defaults, allowing you to breeze through by just pressing Enter. In our guide, we only customized a few options (like choosing Pino for faster logging and enabling Dead Letter Queues for Kafka).

Here is how our choices compare against the CLI's default settings and alternative integrations:

Step 3: Boot Up the Infrastructure

Once the CLI finishes generating the code, all your infrastructure is ready to go. No writing Docker files from scratch.

cd user-service

cp .env.example .env

docker-compose up -d

npm run start:dev

Because of how the CLI scaffolds the project, Kafka boots in KRaft mode with a special initialization container. You will see Postgres, Redis, and Kafka all start up perfectly without any race conditions.

Just like that, you have a production-ready microservice running in under 2 minutes.

Note: you might get kafka-topic related error at startup, you can simply restart the application after a few seconds, and topic will be created or you can exec into docker and create the topic manually.

🌐 Interactive Developer Playgrounds

If you enabled Swagger API Docs or GraphQL, the CLI pre-configures and exposes rich, interactive playgrounds out of the box so you can immediately execute and test operations:

Swagger API Playground (REST)

Access the auto-generated Swagger UI at http://localhost:3000/api/docs to see your REST endpoints, database CRUD examples, and health checks beautifully laid out:

🏗️ What Exactly Gets Generated?

candy-nest-cli dynamically generates only the modules you asked for.

Here is a look at the generated project structure for the service we just built:

Let me know what you think in the comments below. Happy coding! 🚀