Schema definition in NestJS - Performance & Optimization

Performance: Schema definition

MEDIUM IMPACT

Schema definitions impact server response time and data validation speed, which indirectly affect frontend load and interaction times.

Defining data validation and structure for API requests

NestJS

import { Schema } from 'mongoose';

const UserSchema = new Schema({
  name: { type: String, required: true },
  age: { type: Number, min: 0, max: 120 },
  address: {
    street: { type: String },
    city: { type: String },
    zip: { type: String }
  }
});

Using explicit nested schemas and strict types improves validation speed and reduces data size.

📈 Performance GainReduces validation time by 20-40% and lowers server CPU load

Defining data validation and structure for API requests

NestJS

import { Schema } from 'mongoose';

const UserSchema = new Schema({
  name: { type: String, required: true },
  age: { type: Number },
  address: { type: Object },
  extra: { type: Schema.Types.Mixed }
});

Using broad types like Object or Mixed causes slower validation and larger data processing overhead.

📉 Performance CostIncreases server CPU usage and delays response by 10-30ms per request

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Loose schema with Mixed/Object types	N/A (server-side)	N/A	N/A	[X] Bad
Strict schema with explicit nested types	N/A (server-side)	N/A	N/A	[OK] Good

Rendering Pipeline

Schema definitions are processed on the server before sending data to the client. Efficient schemas reduce server processing time, which improves the speed of sending data to the browser and thus affects the interaction responsiveness.

→Server Validation

→Data Serialization

→Network Transfer

⚠️ BottleneckServer Validation stage is most expensive when schemas are complex or loosely defined.

Core Web Vital Affected

INP

Schema definitions impact server response time and data validation speed, which indirectly affect frontend load and interaction times.

Optimization Tips

1Avoid using broad types like Mixed or Object in schemas.

2Define explicit nested types for better validation performance.

3Efficient schemas reduce server CPU load and improve interaction responsiveness.

Performance Quiz - 3 Questions

How does using broad types like Mixed or Object in NestJS schemas affect performance?

A It speeds up server validation

B It slows down server validation and increases response time

C It reduces network payload size

D It improves browser rendering speed

DevTools: Network

How to check: Open DevTools, go to Network tab, inspect API response times and payload sizes for endpoints using schemas.

What to look for: Look for lower server response times and smaller payload sizes indicating efficient schema usage.

Practice

1. What is the main purpose of using @Schema() in NestJS?

easy

A. To define the structure and rules of a data model

B. To create a new controller

C. To handle HTTP requests

D. To style components

Solution

1. Step 1: Understand the role of @Schema()

   @Schema() is used to define how data should be structured and validated in NestJS models.

2. Step 2: Compare with other options

   Creating controllers, handling HTTP requests, and styling components are unrelated to schema definition.

3. Final Answer:

   To define the structure and rules of a data model -> Option A

4. Quick Check:

   Schema decorator defines data structure [OK]

Hint: Remember: @Schema() sets data shape, not controllers or styles [OK]

Common Mistakes:

• Confusing @Schema() with controller decorators
• Thinking @Schema() handles HTTP logic
• Mixing schema with UI styling

2. Which of the following is the correct way to define a string property named title in a NestJS schema?

easy

A. @Prop() title: number;

B. @Prop() title: string;

C. @Prop() title = 123;

D. @Prop() title: boolean;

Solution

1. Step 1: Identify the correct type for a string property

   The property title should be of type string to hold text data.

2. Step 2: Check the syntax of @Prop()

   The correct syntax is @Prop() title: string; which declares a string property.

3. Final Answer:

   @Prop() title: string; -> Option B

4. Quick Check:

   String property uses type string [OK]

Hint: Use @Prop() with correct TypeScript type for properties [OK]

Common Mistakes:

• Using wrong types like number or boolean for string data
• Assigning values instead of declaring types
• Missing @Prop() decorator

3. Given this schema snippet:

@Schema()
export class Book {
  @Prop()
  author: string;

  @Prop({ required: true })
  pages: number;
}

What happens if you try to save a Book without pages?

medium

A. The save will throw a syntax error

B. The save will succeed and pages will be undefined

C. The save will succeed and pages will default to 0

D. The save will fail because pages is required

Solution

1. Step 1: Understand the required: true option

   The pages property is marked as required, so it must be provided when saving.

2. Step 2: Predict behavior when missing required property

   Omitting pages causes validation to fail and the save operation to be rejected.

3. Final Answer:

   The save will fail because pages is required -> Option D

4. Quick Check:

   Required props must be present [OK]

Hint: Required props block save if missing [OK]

Common Mistakes:

• Assuming missing required props default silently
• Confusing validation errors with syntax errors
• Ignoring the required option in @Prop()

4. Identify the error in this schema definition:

@Schema()
export class User {
  @Prop({ type: String })
  age: number;
}

medium

A. No error, this is correct

B. Missing @Schema() decorator

C. The type in @Prop() does not match the property type

D. Property name cannot be 'age'

Solution

1. Step 1: Compare @Prop() type and property type

   The decorator says type: String but the property is declared as number.

2. Step 2: Understand type mismatch consequences

   This mismatch can cause runtime errors or incorrect schema behavior.

3. Final Answer:

   The type in @Prop() does not match the property type -> Option C

4. Quick Check:

   Decorator type must match property type [OK]

Hint: Match @Prop() type with property type exactly [OK]

Common Mistakes:

• Using wrong type in @Prop() options
• Ignoring type mismatch warnings
• Assuming property name causes errors

5. How would you define a schema for a Product with a required name (string), optional price (number), and a default inStock (boolean) set to true?

hard

A. @Schema()
export class Product {
@Prop({ required: true })
name: string;

@Prop()
price?: number;

@Prop({ default: true })
inStock: boolean;
}

B. @Schema()
export class Product {
@Prop()
name: string;

@Prop({ required: true })
price: number;

@Prop({ default: false })
inStock: boolean;
}

C. @Schema()
export class Product {
@Prop({ required: true })
name: number;

@Prop()
price: string;

@Prop({ default: true })
inStock: boolean;
}

D. @Schema()
export class Product {
@Prop({ required: true })
name: string;

@Prop({ default: 0 })
price: number;

@Prop()
inStock: boolean;
}

Solution

1. Step 1: Define required name as string

   Use @Prop({ required: true }) name: string; to make name mandatory.

2. Step 2: Define optional price as number

   Use @Prop() price?: number; to allow price to be optional.

3. Step 3: Define inStock with default true

   Use @Prop({ default: true }) inStock: boolean; to set default value.

4. Final Answer:

   Schema with required name (string), optional price (number), and inStock default true -> Option A

5. Quick Check:

   Required, optional, default props set properly [OK]

Hint: Use required, optional ?, and default in @Prop() [OK]

Common Mistakes:

• Mixing types for properties
• Forgetting to mark required props
• Setting wrong default values