Why production readiness matters in NestJS - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why is error handling crucial in production NestJS apps?

In a NestJS application running in production, why is proper error handling important?

A It makes the app run faster by skipping error checks.

B It prevents the app from starting if any error exists in the code.

C It allows the app to ignore user input validation.

D It helps to catch and log errors so the app can recover or fail gracefully without crashing.

💡 Hint

Think about what happens if an unexpected error occurs in a live app.

Proper error handling ensures the app does not crash unexpectedly and helps developers track issues through logs.

❓ component_behavior

intermediate

What happens if you disable logging in a NestJS production app?

Consider a NestJS app running in production with logging disabled. What is the likely outcome?

A The app will run faster and never crash.

B The app will automatically fix errors without logs.

C You lose visibility into app behavior and errors, making debugging difficult.

D Users will see detailed error messages on the screen.

💡 Hint

Think about how logs help developers after deployment.

Logging is essential in production to monitor app health and diagnose issues quickly.

❓ lifecycle

advanced

How does NestJS lifecycle hooks help in production readiness?

Which NestJS lifecycle hook is best suited to perform cleanup tasks before the app shuts down in production?

A beforeApplicationShutdown

B onApplicationBootstrap

C afterApplicationBootstrap

D onModuleInit

💡 Hint

Consider which hook runs just before the app stops.

The beforeApplicationShutdown hook allows cleanup like closing database connections before shutdown.

❓ state_output

advanced

What is the output of this NestJS service in production mode?

Given this NestJS service code snippet running in production mode, what will be logged?

NestJS

import { Injectable, Logger } from '@nestjs/common';

@Injectable()
export class AppService {
  private readonly logger = new Logger(AppService.name);

  getHello(): string {
    this.logger.debug('Debug message');
    this.logger.log('Log message');
    return 'Hello World!';
  }
}

// Assume NestJS default logger settings in production mode

A Only 'Log message' will be logged; 'Debug message' is ignored in production.

B Both 'Debug message' and 'Log message' will be logged.

C No messages will be logged in production mode.

D 'Debug message' will be logged but 'Log message' will not.

💡 Hint

Think about NestJS default log levels in production.

By default, NestJS logger outputs 'log', 'warn', and 'error' levels in production mode. 'debug' messages are ignored unless explicitly enabled.

📝 Syntax

expert

What happens with non-numeric param in typed NestJS controller?

Consider this NestJS controller method. What happens when calling GET /users/abc?

NestJS

import { Controller, Get, Param } from '@nestjs/common';

@Controller('users')
export class UserController {
  @Get(':id')
  getUser(@Param('id') id: number) {
    return `User ID is ${id}`;
  }
}

A Calling GET /users/abc causes a runtime error because 'abc' is not a number.

B Calling GET /users/abc returns 'User ID is abc'.

C Calling GET /users/123 returns 'User ID is 123'.

D Calling GET /users/123 causes a runtime error because '123' is a string.

💡 Hint

Consider how NestJS handles parameter types in @Param decorator.

The @Param decorator always returns string values. The method expects a number but does not convert it, so 'id' is a string. No runtime error occurs; the string is used as is.

Practice

1. Why is production readiness important for a NestJS application?

easy

A. It helps the app use less memory in testing environments.

B. It makes the app run faster only during development.

C. It automatically writes the app's documentation.

D. It ensures the app is stable, secure, and performs well under real use.

Solution

1. Step 1: Understand production readiness goals

   Production readiness focuses on stability, security, and performance in real use, not just development or testing.

2. Step 2: Compare options to goals

   Only It ensures the app is stable, secure, and performs well under real use. matches these goals by ensuring the app is stable, secure, and performs well under real use.

3. Final Answer:

   It ensures the app is stable, secure, and performs well under real use. -> Option D

4. Quick Check:

   Production readiness = stability, security, performance [OK]

Hint: Focus on stability, security, and performance in real use [OK]

Common Mistakes:

• Confusing development speed with production readiness
• Thinking it only affects memory usage in tests
• Assuming it auto-generates documentation

2. Which of the following is a correct way to manage configuration for production readiness in NestJS?

easy

A. Store configuration only in a JSON file inside the public folder.

B. Hardcode all settings directly in the source code.

C. Use environment variables and a configuration module.

D. Ask users to input configuration every time the app starts.

Solution

1. Step 1: Identify best practice for config management

   Using environment variables and a configuration module is the standard way to manage settings safely and flexibly.

2. Step 2: Evaluate options

   Use environment variables and a configuration module. matches best practice; others either hardcode, expose config publicly, or require manual input each start, which is impractical.

3. Final Answer:

   Use environment variables and a configuration module. -> Option C

4. Quick Check:

   Config management = env variables + config module [OK]

Hint: Use environment variables for flexible config [OK]

Common Mistakes:

• Hardcoding sensitive info in code
• Exposing config files publicly
• Requiring manual config input every start

3. Consider this NestJS code snippet for error handling in production:

app.useGlobalFilters(new AllExceptionsFilter());

// Inside AllExceptionsFilter class
catch(exception, host) {
  const ctx = host.switchToHttp();
  const response = ctx.getResponse();
  const status = exception.getStatus ? exception.getStatus() : 500;
  response.status(status).json({
    statusCode: status,
    message: 'Internal server error',
  });
}

What will the client receive if an unexpected error occurs?

medium

A. A JSON response with statusCode 500 and message 'Internal server error'.

B. A plain text error message with status 200.

C. No response because the error is not caught.

D. A JSON response with statusCode 200 and message 'Success'.

Solution

1. Step 1: Analyze the catch method behavior

   The catch method sets status to exception.getStatus() if available, else 500. It sends JSON with statusCode and message 'Internal server error'.

2. Step 2: Determine response for unexpected error

   Unexpected errors lack getStatus(), so status is 500. The client gets JSON with statusCode 500 and message 'Internal server error'.

3. Final Answer:

   A JSON response with statusCode 500 and message 'Internal server error'. -> Option A

4. Quick Check:

   Unexpected error -> status 500 + JSON message [OK]

Hint: Unexpected errors default to status 500 with JSON message [OK]

Common Mistakes:

• Assuming status 200 on errors
• Thinking error is uncaught
• Expecting plain text instead of JSON

4. You have this NestJS code snippet for logging:

import { Logger } from '@nestjs/common';

const logger = new Logger('AppModule');

function startApp() {
  logger.log('Starting app...');
  // Missing logger.error usage here
}

startApp();

What is the main issue regarding production readiness?

medium

A. There is no error logging to capture failures.

B. The logger should be imported from 'nestjs/core' instead.

C. The log message uses the wrong method name.

D. The logger instance is not created correctly.

Solution

1. Step 1: Check logger usage in code

   The code creates a logger and logs a normal message but does not log errors anywhere.

2. Step 2: Understand production readiness logging needs

   Production readiness requires error logging to track failures. Missing error logs means issues may go unnoticed.

3. Final Answer:

   There is no error logging to capture failures. -> Option A

4. Quick Check:

   Error logging missing = problem for production readiness [OK]

Hint: Check if errors are logged, not just info messages [OK]

Common Mistakes:

• Thinking logger import path is wrong
• Assuming logger instance creation is incorrect
• Confusing log method names

5. You want to prepare your NestJS app for production by adding health checks, logging, and config management. Which combination of steps best ensures production readiness?

hard

A. Write custom health check code, console.log for logs, and hardcode config in main.ts.

B. Use @nestjs/terminus for health checks, Logger for logs, and ConfigModule with env variables.

C. Skip health checks, use third-party logging unrelated to NestJS, and store config in public JSON.

D. Only add health checks; logging and config are optional in production.

Solution

1. Step 1: Identify recommended tools for production readiness

   @nestjs/terminus is the official health check module, Logger is the built-in logging tool, and ConfigModule with env variables is best practice for config.

2. Step 2: Evaluate options for completeness and best practices

   Use @nestjs/terminus for health checks, Logger for logs, and ConfigModule with env variables. uses all recommended tools properly. Others either skip important parts or use poor practices.

3. Final Answer:

   Use @nestjs/terminus for health checks, Logger for logs, and ConfigModule with env variables. -> Option B

4. Quick Check:

   Health + logging + config with NestJS tools = production ready [OK]

Hint: Combine official NestJS tools for health, logging, and config [OK]

Common Mistakes:

• Ignoring health checks or logging
• Hardcoding config instead of env variables
• Using unrelated or insecure tools