TypeScript-first philosophy in NestJS - Step-by-Step Execution

Concept Flow - TypeScript-first philosophy

Write code in TypeScript

↓

Use decorators and types

↓

Compile to JavaScript

↓

Run compiled JavaScript in Node.js

↓

Enjoy type safety and autocompletion

↓

Catch errors early during development

↓

Maintain scalable, readable code

The flow shows how NestJS encourages writing code in TypeScript first, using types and decorators, then compiling to JavaScript to run, which helps catch errors early and improves code quality.

Execution Sample

NestJS

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

@Controller('hello')
export class HelloController {
  @Get()
  sayHello(): string {
    return 'Hello, TypeScript!';
  }
}

This NestJS controller uses TypeScript types and decorators to define a simple GET endpoint returning a string.

Execution Table

Step	Action	TypeScript Feature	Effect	Output/Result
1	Define HelloController class	class with @Controller decorator	Class registered as controller for 'hello' route	No output yet
2	Define sayHello method	method with @Get decorator and return type string	Method registered as GET handler	No output yet
3	Compile TypeScript to JavaScript	Type annotations removed, decorators preserved	JavaScript code ready to run	No output yet
4	Run compiled code in Node.js	JavaScript runtime executes code	Server listens on /hello GET route	No output yet
5	Client sends GET request to /hello	Runtime calls sayHello method	Method returns string 'Hello, TypeScript!'	Response: 'Hello, TypeScript!'
6	TypeScript checks types during development	Static type checking	Errors caught before runtime	No runtime errors related to types

💡 Execution stops after responding to GET request; TypeScript-first approach ensures type safety before runtime.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	Final
HelloController	undefined	Class defined	Method added	Compiled to JS	Loaded in runtime	Instance handles request	Class remains for server lifetime
sayHello()	undefined	undefined	Method defined with return type	Compiled to JS function	Callable function	Returns string 'Hello, TypeScript!'	Function ready for next calls

Key Moments - 3 Insights

Why do we write types in TypeScript if they disappear after compilation?

Types help catch errors during development before running the code, as shown in step 6 of the execution_table where static type checking prevents runtime errors.

How do decorators like @Controller and @Get work with TypeScript-first philosophy?

Decorators add metadata to classes and methods that NestJS uses at runtime, shown in steps 1 and 2 where decorators register routes, enabling clear structure and type safety.

What happens if we send a request to a route not defined in the controller?

The server will not find a matching handler, resulting in a 404 error; this is outside the TypeScript type system but handled by NestJS routing at runtime.

Visual Quiz - 3 Questions

Look at the execution_table, what is the output at step 5 when the GET request is handled?

A Undefined

B An error message

C 'Hello, TypeScript!'

D Empty response

💡 Hint

Check the Output/Result column at step 5 in the execution_table.

At which step does TypeScript remove type annotations and prepare code for runtime?

A Step 3

B Step 2

C Step 4

D Step 6

💡 Hint

Look at the Action and TypeScript Feature columns in the execution_table.

If we remove the @Get decorator from sayHello, what changes in the execution?

A The method will still handle GET requests

B The method will not be registered as a route handler

C TypeScript will throw a compile error

D The server will crash at runtime

💡 Hint

Refer to steps 1 and 2 in the execution_table about decorators registering routes.

Concept Snapshot

TypeScript-first philosophy in NestJS means:
- Write code using TypeScript with types and decorators
- Compile to JavaScript for Node.js runtime
- Use decorators (@Controller, @Get) to define routes
- Catch errors early with static type checking
- Improve code readability and maintainability
- Run safe, scalable server applications

Full Transcript

In NestJS, the TypeScript-first philosophy means you write your server code using TypeScript. You use types to describe data and decorators like @Controller and @Get to define routes. When you compile, TypeScript removes types but keeps decorators. The compiled JavaScript runs in Node.js. This approach helps catch mistakes early during development, before running the code. For example, a HelloController class with a sayHello method decorated with @Get returns a string when a client requests the /hello route. The flow starts with writing TypeScript, compiling it, running the server, and handling requests. Variables like the controller class and methods are defined and used step-by-step. Key points include understanding that types help during development but are not in the final code, decorators register routes, and missing decorators mean routes won't work. Quizzes test understanding of outputs, compilation steps, and decorator roles. This philosophy leads to safer, clearer, and more maintainable backend code.

Practice

1. What is the main benefit of the TypeScript-first philosophy in NestJS?

easy

A. It makes the app run faster at runtime.

B. It removes the need for any testing.

C. It helps catch errors early by using types.

D. It allows writing code without any types.

Solution

1. Step 1: Understand TypeScript's role

   TypeScript adds types to JavaScript, which helps find mistakes before running the code.

2. Step 2: Connect to NestJS philosophy

   NestJS uses TypeScript-first to improve code safety and clarity by leveraging types.

3. Final Answer:

   It helps catch errors early by using types. -> Option C

4. Quick Check:

   TypeScript-first = catch errors early [OK]

Hint: TypeScript-first means using types to find errors early [OK]

Common Mistakes:

• Thinking it makes runtime faster
• Believing it removes need for tests
• Assuming it means no types needed

2. Which of the following is the correct way to define a typed controller method in NestJS using TypeScript-first philosophy?

easy

A. async getUser(): Promise<User> { return this.userService.find(); }

B. async getUser() { return this.userService.find(); }

C. async getUser(): any { return this.userService.find(); }

D. async getUser(): string { return this.userService.find(); }

Solution

1. Step 1: Check method return type

   TypeScript-first means explicitly typing the return value, here Promise<User>.

2. Step 2: Compare options

   async getUser(): Promise<User> { return this.userService.find(); } uses correct typing; others omit or use wrong types like any or string.

3. Final Answer:

   async getUser(): Promise<User> { return this.userService.find(); } -> Option A

4. Quick Check:

   Explicit return type = async getUser(): Promise<User> { return this.userService.find(); } [OK]

Hint: Always specify method return types explicitly [OK]

Common Mistakes:

• Omitting return type annotation
• Using 'any' instead of specific types
• Using wrong return types like string

3. Given this NestJS service method using TypeScript-first philosophy:

async findUser(id: number): Promise {
  const user = await this.userRepository.findOneBy({ id });
  return user ?? null;
}

What is the type of the value returned when no user is found?

medium

A. undefined

B. an empty object {}

C. throws an error

D. null

Solution

1. Step 1: Analyze return statement

   The method returns user ?? null, which means if user is nullish, return null.

2. Step 2: Understand nullish coalescing

   If findOneBy returns undefined, the expression returns null explicitly.

3. Final Answer:

   null -> Option D

4. Quick Check:

   Nullish coalescing returns null if no user [OK]

Hint: ?? operator returns right side if left is null or undefined [OK]

Common Mistakes:

• Assuming undefined is returned
• Thinking an error is thrown
• Expecting empty object instead of null

4. Identify the error in this NestJS controller method using TypeScript-first philosophy:

@Get(':id')
async getUser(@Param('id') id: string): Promise<User> {
  return this.userService.findUser(id);
}

medium

A. The method should not be async if it returns a Promise.

B. The return type should be Promise if user might not exist.

C. The parameter id should be typed as number not string.

D. The decorator @Get is missing a path.

Solution

1. Step 1: Check return type correctness

   If findUser can return null when user not found, the controller must reflect that in its return type.

2. Step 2: Compare options

   The return type should be Promise if user might not exist. correctly points out the return type should allow null. The parameter id should be typed as number not string. is not always true because id can be string if parsed later.

3. Final Answer:

   The return type should be Promise if user might not exist. -> Option B

4. Quick Check:

   Return type must match possible null values [OK]

Hint: Return types must include null if possible [OK]

Common Mistakes:

• Ignoring possible null return
• Thinking async keyword is wrong here
• Assuming @Get needs path always

5. You want to create a NestJS DTO (Data Transfer Object) that enforces a required name string and an optional age number using TypeScript-first philosophy. Which of these is the best TypeScript definition?

hard

A. export class CreateUserDto { name: string; age?: number; }

B. export interface CreateUserDto { name?: string; age: number; }

C. export type CreateUserDto = { name?: string; age?: number; };

D. export class CreateUserDto { name?: string; age: number; }

Solution

1. Step 1: Identify required and optional properties

   The name must be required (no question mark), age optional (with question mark).

2. Step 2: Match with options

   export class CreateUserDto { name: string; age?: number; } correctly defines name as required and age as optional in a class, which is standard for NestJS DTOs.

3. Final Answer:

   export class CreateUserDto { name: string; age?: number; } -> Option A

4. Quick Check:

   Required name, optional age = export class CreateUserDto { name: string; age?: number; } [OK]

Hint: Use '?' for optional properties, omit for required [OK]

Common Mistakes:

• Marking required fields as optional
• Using interface instead of class for DTO
• Making optional fields required