Entity definition in NestJS - Performance & Optimization

Performance: Entity definition

MEDIUM IMPACT

Entity definitions affect the initial database schema creation and runtime ORM operations, impacting server response time and query efficiency.

Defining a database entity with relations in NestJS using TypeORM

NestJS

import { Entity, PrimaryGeneratedColumn, Column, OneToMany } from 'typeorm';

@Entity()
export class User {
  @PrimaryGeneratedColumn()
  id: number;

  @Column()
  name: string;

  @OneToMany(() => Post, post => post.user, { lazy: true })
  posts: Promise<Post[]>;
}

Lazy loading defers loading related posts until explicitly requested, reducing initial query size and response time.

📈 Performance GainReduces initial query size and memory usage, improving response time by 50-100ms depending on data size.

Defining a database entity with relations in NestJS using TypeORM

NestJS

import { Entity, PrimaryGeneratedColumn, Column, OneToMany } from 'typeorm';

@Entity()
export class User {
  @PrimaryGeneratedColumn()
  id: number;

  @Column()
  name: string;

  @OneToMany(() => Post, post => post.user, { eager: true })
  posts: Post[];
}

Using eager loading on a OneToMany relation causes all related posts to load every time a user is fetched, increasing query time and memory usage.

📉 Performance CostTriggers large JOIN queries and loads unnecessary data, increasing response time by 100ms+ on large datasets.

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Eager loading large relations in entity	N/A (server-side)	N/A	N/A	[X] Bad
Lazy loading relations on demand	N/A (server-side)	N/A	N/A	[OK] Good

Rendering Pipeline

Entity definitions influence how ORM generates SQL queries and fetches data, affecting server-side processing before sending data to the client.

→Query Generation

→Database Fetch

→Data Serialization

⚠️ BottleneckDatabase Fetch due to inefficient queries or eager loading of large relations.

Optimization Tips

1Avoid eager loading large or deep relations in entity definitions.

2Use lazy loading to fetch related data only when necessary.

3Select only required fields in queries to reduce data size.

Performance Quiz - 3 Questions

What is a performance downside of using eager loading in NestJS entity relations?

A It delays loading related data until explicitly requested.

B It reduces database query size by selecting fewer fields.

C It loads all related data even if not needed, increasing response time.

D It caches data on the client to improve speed.

DevTools: Network

How to check: Open DevTools Network tab, inspect API responses for payload size and response time when fetching entities.

What to look for: Look for large JSON payloads or slow response times indicating heavy or inefficient entity loading.

Practice

1. What is the purpose of the @Entity() decorator in a NestJS application using TypeORM?

easy

A. It marks a class as a database table representation.

B. It defines a method to fetch data from the database.

C. It creates a new database connection.

D. It styles the output of a component.

Solution

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

   The @Entity() decorator tells NestJS and TypeORM that the class represents a database table.

2. Step 2: Differentiate from other decorators

   Other decorators like @Column() define table columns, but @Entity() marks the whole class as a table.

3. Final Answer:

   It marks a class as a database table representation. -> Option A

4. Quick Check:

   @Entity() = Table marker [OK]

Hint: Remember: @Entity() means 'this class is a table' [OK]

Common Mistakes:

• Confusing @Entity() with database connection setup
• Thinking @Entity() defines methods or styles
• Mixing up @Entity() with @Column()

2. Which of the following is the correct way to define a string column named title in a NestJS entity using TypeORM?

easy

A. @Column({ type: 'number' }) title: string;

B. @Column('boolean') title: string;

C. @Column() title: string;

D. @Column({ length: 255 }) title: number;

Solution

1. Step 1: Identify the correct @Column() usage for a string

   By default, @Column() without options assumes a string type in TypeORM.

2. Step 2: Check type consistency

   The property type should be string to match the column type.

3. Final Answer:

   @Column() title: string; -> Option C

4. Quick Check:

   Default @Column() = string column [OK]

Hint: Use @Column() alone for simple string columns [OK]

Common Mistakes:

• Setting wrong type in @Column() options
• Mismatching property type and column type
• Using number type for string properties

3. Given the following entity code, what will be the type of the age column in the database?

import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm';

@Entity()
export class User {
  @PrimaryGeneratedColumn()
  id: number;

  @Column()
  name: string;

  @Column({ type: 'int' })
  age: number;
}

medium

A. INTEGER (number)

B. VARCHAR (string)

C. BOOLEAN

D. DATE

Solution

1. Step 1: Check the @Column() decorator on age

   The decorator specifies { type: 'int' }, which means an integer column in the database.

2. Step 2: Match the property type

   The property age is a number, matching the integer database type.

3. Final Answer:

   INTEGER (number) -> Option A

4. Quick Check:

   { type: 'int' } means integer column [OK]

Hint: Look for { type: 'int' } to identify integer columns [OK]

Common Mistakes:

• Assuming default string type without checking options
• Confusing int with boolean or date
• Ignoring the explicit type option in @Column()

4. Identify the error in the following entity definition:

import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm';

@Entity()
export class Product {
  @PrimaryGeneratedColumn()
  id: number;

  @Column({ type: 'varchar', length: 100 })
  name: number;
}

medium

A. Missing @Entity() decorator

B. Property type number does not match column type varchar

C. Primary key column missing

D. Incorrect import statement

Solution

1. Step 1: Check property and column type consistency

   The name property is typed as number but the column type is varchar, which expects a string.

2. Step 2: Confirm other parts are correct

   @Entity() is present, primary key is defined, and imports are correct.

3. Final Answer:

   Property type number does not match column type varchar -> Option B

4. Quick Check:

   Property type must match column type [OK]

Hint: Match property type with @Column() type options [OK]

Common Mistakes:

• Using wrong property type for string columns
• Forgetting to add @Entity()
• Missing primary key decorator

5. You want to define an entity Order with an auto-generated primary key id, a string customerName limited to 150 characters, and an optional numeric discount that can be null. Which is the correct entity definition?

hard

A. import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm';

@Entity()
export class Order {
@PrimaryGeneratedColumn()
id: number;

@Column({ length: 150 })
customerName: string;

@Column({ type: 'int', nullable: false })
discount: number;
}

B. import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm';

@Entity()
export class Order {
@PrimaryGeneratedColumn()
id: string;

@Column({ length: 150 })
customerName: string;

@Column({ type: 'float' })
discount: number;
}

C. import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm';

@Entity()
export class Order {
@PrimaryGeneratedColumn()
id: number;

@Column({ type: 'varchar', length: 150 })
customerName: number;

@Column({ type: 'float', nullable: true })
discount: number;
}

D. import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm';

@Entity()
export class Order {
@PrimaryGeneratedColumn()
id: number;

@Column({ length: 150 })
customerName: string;

@Column({ type: 'float', nullable: true })
discount?: number;
}

Solution

1. Step 1: Verify primary key definition

   @PrimaryGeneratedColumn() on id: number creates an auto-incrementing integer primary key. A string type would be incorrect without additional configuration like UUID.

2. Step 2: Check customerName

   @Column({ length: 150 }) with string type creates a VARCHAR(150) column. A number type mismatches.

3. Step 3: Confirm discount

   @Column({ type: 'float', nullable: true }) with optional discount?: number allows null values. Missing nullable: true, wrong type like 'int', or non-optional fails.

4. Final Answer:

   The entity with number id, string customerName({length:150}), optional nullable float discount -> Option D

5. Quick Check:

   Match types, nullable, and optional properties carefully [OK]

Hint: Use nullable: true and optional property for nullable columns [OK]

Common Mistakes:

• Mismatching property types and column types
• Forgetting to mark nullable columns as optional
• Using wrong primary key type