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.