NestJS CRUD Operations Tutorial Using TypeORM

You now have all the individual pieces, entities, repositories, controllers, DTOs, and validation, needed to build a genuinely complete, production-shaped REST API. This lesson brings everything together into one cohesive example: a full CRUD (Create, Read, Update, Delete) resource for managing products, built using TypeORM's repository pattern from end to end.

Rather than introducing new concepts, this lesson focuses on integration: showing precisely how a controller, a DTO, and a service backed by a TypeORM repository work together to form one complete, realistic feature.

NestJS CRUD TypeORM: Learning Objectives

• Build a complete CRUD resource combining a controller, DTOs, and a TypeORM-backed service.
• Implement Create, Read (list and single), Update, and Delete operations using repository methods.
• Handle the 'not found' case correctly when updating or deleting a non-existent record.
• Apply validation and DTOs consistently across all write operations.
• Understand how HTTP status codes map naturally onto each CRUD operation.

NestJS CRUD TypeORM: Key Terms and Definitions

• CRUD: An acronym for Create, Read, Update, Delete, representing the four fundamental operations most resources in a REST API support.
• Upsert: An operation that inserts a new record if it doesn't exist, or updates it if it does; distinct from a plain update.
• Soft delete: A pattern where a record is marked as deleted (e.g. via a flag or timestamp) rather than physically removed from the database.
• DeleteResult / UpdateResult: Objects returned by TypeORM's delete() and update() methods describing how many rows were affected.
• 204 No Content: An HTTP status code commonly used for successful DELETE requests that do not return a response body.

How NestJS CRUD TypeORM Works: Detailed Explanation

A complete CRUD resource in a TypeORM-backed NestJS application follows a highly consistent shape across every feature you build, which is precisely why mastering this one example pays off across your entire career. The Create operation accepts a validated DTO via @Body(), uses the repository's create() method to build a new entity instance, and save() to persist it, typically returning the newly created record along with a 201 Created status.

The Read operation actually splits into two distinct patterns: listing all records, typically via repository.find() (often combined with pagination, covered in a later lesson), and retrieving a single record by ID using repository.findOne({ where: { id } }). This second case introduces an important design decision: what should happen if no record matches the given ID? The correct, idiomatic approach is to explicitly check whether findOne() returned null and, if so, throw a NotFoundException, ensuring the client receives a clear 404 response rather than a confusing null or empty response body.

The Update operation combines a route parameter identifying which record to update with a request body (typically typed against an UpdateDto with optional fields) describing the changes. A common, efficient pattern uses the repository's update() method directly, which performs an UPDATE query without first loading the entity into memory, though many applications prefer first calling findOne() to confirm the record exists (throwing NotFoundException if not) before proceeding, especially when the response should include the fully updated entity.

The Delete operation similarly combines a route parameter with the repository's delete() method, which returns a DeleteResult object indicating how many rows were affected. Checking this affected count (or, again, first calling findOne()) allows you to correctly return a 404 if the record didn't exist, rather than silently succeeding on an operation that effectively did nothing. Successful deletions commonly return a 204 No Content status with an empty response body, signaling that the operation succeeded but there is no meaningful data to return.

Interview-Friendly Explanation

A strong interview or viva answer for nestjs crud typeorm must go beyond a one-line definition. Interviewers evaluating BCA, MCA, B.Tech, and self-taught backend developers reward answers that combine a precise definition, a clear working explanation, a real-world example, and a conclusion that highlights why it matters in production Node.js applications. Use the four-point framework below when answering under time pressure.

• Definition point: CRUD: An acronym for Create, Read, Update, Delete, representing the four fundamental operations most resources in a REST API support.
• Working point: Implement Create, Read (list and single), Update, and Delete operations using repository methods.
• Example point: Nearly every internal admin tool and public-facing API in a NestJS company codebase follows this exact CRUD shape for each of its core resources, whether products, customers, or invoices.
• Conclusion point: A complete CRUD resource is really just five consistent, well-understood pieces working together: entity, DTOs, service, controller, and repository calls.

How to Answer This in a Technical Interview

1. Give a two-to-three sentence definition using correct database and ORM terminology.
2. Add one specific example drawn from a real backend scenario such as an e-commerce, fintech, or SaaS database schema.
3. Mention any trade-offs versus alternative approaches (e.g. TypeORM vs Prisma, SQL vs NoSQL) since interviewers often probe this contrast.
4. Close with one benefit, limitation, or production use case.
5. Avoid vague answers like "it just connects to the database" — interviewers filter these out immediately.

Practical Scenario

Imagine you are designing the data layer for a production SaaS product, similar to systems used at companies like Razorpay, Freshworks, or Zomato. Every lesson in this module maps directly to a decision you will make while building that backend: how data is structured, how it's queried efficiently, how relationships between entities are modeled, and how the schema evolves safely over time as the product grows.

NestJS CRUD TypeORM: Architecture and Flow Diagram

Visualize a complete CRUD resource mapped to HTTP methods and repository calls:

POST /products --> ProductsService.create() --> repository.create() + repository.save()
GET /products --> ProductsService.findAll() --> repository.find()
GET /products/:id --> ProductsService.findOne() --> repository.findOne({ where: { id } })
PATCH /products/:id --> ProductsService.update() --> repository.update(id, dto)
DELETE /products/:id --> ProductsService.remove() --> repository.delete(id)

NestJS CRUD TypeORM: Operation Reference Table

Operation	HTTP Method	Repository Method(s)	Success Status
Create	POST	create() + save()	201 Created
Read all	GET	find()	200 OK
Read one	GET /:id	findOne({ where: { id } })	200 OK (or 404 if not found)
Update	PATCH /:id	update(id, dto) or findOne() + save()	200 OK (or 404 if not found)
Delete	DELETE /:id	delete(id)	204 No Content (or 404 if not found)

NestJS CRUD TypeORM: NestJS Code Example

// dto/create-product.dto.ts
import { IsString, IsNotEmpty, IsNumber, Min } from 'class-validator';

export class CreateProductDto {
  @IsString()
  @IsNotEmpty()
  name: string;

  @IsNumber()
  @Min(0)
  price: number;
}

// dto/update-product.dto.ts
import { PartialType } from '@nestjs/mapped-types';
import { CreateProductDto } from './create-product.dto';

export class UpdateProductDto extends PartialType(CreateProductDto) {}

// products.service.ts — full CRUD using TypeORM repository
import { Injectable, NotFoundException } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { Product } from './product.entity';
import { CreateProductDto } from './dto/create-product.dto';
import { UpdateProductDto } from './dto/update-product.dto';

@Injectable()
export class ProductsService {
  constructor(
    @InjectRepository(Product)
    private readonly productRepository: Repository<Product>,
  ) {}

  async create(dto: CreateProductDto): Promise<Product> {
    const product = this.productRepository.create(dto);
    return this.productRepository.save(product);
  }

  findAll(): Promise<Product[]> {
    return this.productRepository.find();
  }

  async findOne(id: number): Promise<Product> {
    const product = await this.productRepository.findOne({ where: { id } });
    if (!product) {
      throw new NotFoundException(`Product with ID ${id} not found`);
    }
    return product;
  }

  async update(id: number, dto: UpdateProductDto): Promise<Product> {
    const product = await this.findOne(id); // reuses findOne to guarantee existence
    Object.assign(product, dto);
    return this.productRepository.save(product);
  }

  async remove(id: number): Promise<void> {
    const result = await this.productRepository.delete(id);
    if (result.affected === 0) {
      throw new NotFoundException(`Product with ID ${id} not found`);
    }
  }
}

// products.controller.ts
import { Controller, Get, Post, Patch, Delete, Param, Body, HttpCode } from '@nestjs/common';
import { ProductsService } from './products.service';
import { CreateProductDto } from './dto/create-product.dto';
import { UpdateProductDto } from './dto/update-product.dto';

@Controller('products')
export class ProductsController {
  constructor(private readonly productsService: ProductsService) {}

  @Post()
  create(@Body() dto: CreateProductDto) {
    return this.productsService.create(dto);
  }

  @Get()
  findAll() {
    return this.productsService.findAll();
  }

  @Get(':id')
  findOne(@Param('id') id: string) {
    return this.productsService.findOne(+id);
  }

  @Patch(':id')
  update(@Param('id') id: string, @Body() dto: UpdateProductDto) {
    return this.productsService.update(+id, dto);
  }

  @Delete(':id')
  @HttpCode(204)
  remove(@Param('id') id: string) {
    return this.productsService.remove(+id);
  }
}

This example demonstrates a fully working CRUD resource end to end. ProductsService.findOne() explicitly throws a NotFoundException when no matching product exists, and this same method is deliberately reused inside update(), ensuring both routes handle a missing record identically and correctly. remove() checks the affected count returned by delete() to detect whether a record actually existed, again throwing NotFoundException if not. In the controller, @HttpCode(204) explicitly overrides NestJS's default 200 status for the DELETE route, since a 204 No Content response is the more correct, conventional status for a successful deletion with no response body.

Real-World NestJS CRUD TypeORM Industry Examples

• Nearly every internal admin tool and public-facing API in a NestJS company codebase follows this exact CRUD shape for each of its core resources, whether products, customers, or invoices.
• E-commerce inventory systems rely heavily on this pattern for managing products, with additional business rules layered into the service methods, such as preventing deletion of a product that has existing orders.
• Content management systems implement nearly identical CRUD patterns for articles, categories, and media assets, often extending the basic pattern with soft deletes instead of true row deletion.
• API testing suites frequently target exactly these five endpoints as their first coverage target for any new resource, since they represent the most fundamental, must-work functionality of any data-driven feature.

NestJS CRUD TypeORM Interview Questions and Answers

Q1. Walk through how you would implement a complete CRUD resource in NestJS using TypeORM.

Short answer: You define an entity representing the resource, create CreateDto and UpdateDto classes with validation rules, build a service injecting the entity's repository that implements create, findAll, findOne, update, and remove methods using repository methods like create(), save(), find(), findOne(), and delete(), and finally build a controller exposing these as POST, GET, GET/:id, PATCH/:id, and DELETE/:id routes respectively.

Detailed explanation: A complete CRUD resource in a TypeORM-backed NestJS application follows a highly consistent shape across every feature you build, which is precisely why mastering this one example pays off across your entire career. The Create operation accepts a validated DTO via @Body(), uses the repository's create() method to build a new entity instance, and save() to persist it, typically returning the newly created record along with a 201 Created status. The Read operation actually splits into two distinct patterns: listing all records, typically via repository.find() (often combined with pagination, covered in a later lesson), and retrieving a single record by ID using repository.findOne({ where: { id } }). This second case introduces an important design decision: what should happen if no record matches the given ID? The correct, idiomatic approach is to explicitly check whether findOne() returned null and, if so, throw a NotFoundException, ensuring the client receives a clear 404 response rather than a confusing null or empty response body. The Update operation combines a route parameter identifying which record to update with a request body (typically typed against an UpdateDto with optional fields) describing the changes. A common, efficient pattern uses the repository's update() method directly, which performs an UPDATE query without first loading the entity into memory, though many applications prefer first calling findOne() to confirm the record exists (throwing NotFoundException if not) before proceeding, especially when the response should include the fully updated entity. The Delete operation similarly combines a route parameter with the repository's delete() method, which returns a DeleteResult object indicating how many rows were affected. Checking this affected count (or, again, first calling findOne()) allows you to correctly return a 404 if the record didn't exist, rather than silently succeeding on an operation that effectively did nothing. Successful deletions commonly return a 204 No Content status with an empty response body, signaling that the operation succeeded but there is no meaningful data to return.

Practical example: Nearly every internal admin tool and public-facing API in a NestJS company codebase follows this exact CRUD shape for each of its core resources, whether products, customers, or invoices.

Interview tip: Standard CRUD mapping: POST (create, 201), GET (read, 200), GET/:id (read one, 200 or 404), PATCH/:id (update, 200 or 404), DELETE/:id (delete, 204 or 404).

Revision hook: A complete CRUD resource is really just five consistent, well-understood pieces working together: entity, DTOs, service, controller, and repository calls.

Q2. How should a service handle a request to update or delete a record that doesn't exist?

Short answer: The service should explicitly check whether the target record exists, either by calling findOne() and checking for null, or by inspecting the affected count returned by an update() or delete() call, and throw a NotFoundException if no matching record was found, ensuring the client receives a clear 404 response instead of a silent, misleading success.

Detailed explanation: This example demonstrates a fully working CRUD resource end to end. ProductsService.findOne() explicitly throws a NotFoundException when no matching product exists, and this same method is deliberately reused inside update(), ensuring both routes handle a missing record identically and correctly. remove() checks the affected count returned by delete() to detect whether a record actually existed, again throwing NotFoundException if not. In the controller, @HttpCode(204) explicitly overrides NestJS's default 200 status for the DELETE route, since a 204 No Content response is the more correct, conventional status for a successful deletion with no response body.

Practical example: E-commerce inventory systems rely heavily on this pattern for managing products, with additional business rules layered into the service methods, such as preventing deletion of a product that has existing orders.

Interview tip: Always explicitly handle the 'not found' case for single-record read, update, and delete operations.

Revision hook: Explicitly handling the 'not found' case is what separates a correct API from one that silently returns confusing or misleading responses.

Q3. Why is 204 No Content commonly used as the success status for a DELETE request?

Short answer: 204 No Content signals that the operation succeeded but there is no meaningful data to return in the response body, which accurately reflects a delete operation, since there is no remaining resource state to send back to the client, unlike a create or update operation which typically does return the resulting resource.

Detailed explanation: A complete CRUD resource in NestJS combines everything covered so far: an entity describing the data shape, CreateDto and UpdateDto classes enforcing validation, a service using an injected TypeORM repository to implement create, findAll, findOne, update, and remove methods, and a controller exposing these through conventional REST routes. Correctly handling cases where a requested record doesn't exist, by throwing NotFoundException based on a null findOne() result or a zero affected count from update() or delete(), is what makes an API predictable and trustworthy. Following HTTP conventions closely, such as 201 Created for new resources and 204 No Content for successful deletions, rounds out a CRUD implementation that matches the shape of real, professional production APIs.

Practical example: Content management systems implement nearly identical CRUD patterns for articles, categories, and media assets, often extending the basic pattern with soft deletes instead of true row deletion.

Interview tip: DeleteResult and UpdateResult objects contain an 'affected' count useful for detecting whether a target record existed.

Revision hook: Reusing methods like findOne() across update() and other operations keeps not-found handling logic consistent throughout a service.

Q4. What is the difference between using repository.update() directly versus calling findOne() first and then save()?

Short answer: repository.update() performs a direct UPDATE query without first loading the entity into memory, which is more efficient but does not return the updated entity itself. Calling findOne() first, applying changes, and then calling save() is slightly less efficient but allows you to easily return the fully updated entity and reuse existing not-found handling logic.

Detailed explanation: A complete CRUD resource in a TypeORM-backed NestJS application follows a highly consistent shape across every feature you build, which is precisely why mastering this one example pays off across your entire career. The Create operation accepts a validated DTO via @Body(), uses the repository's create() method to build a new entity instance, and save() to persist it, typically returning the newly created record along with a 201 Created status. The Read operation actually splits into two distinct patterns: listing all records, typically via repository.find() (often combined with pagination, covered in a later lesson), and retrieving a single record by ID using repository.findOne({ where: { id } }). This second case introduces an important design decision: what should happen if no record matches the given ID? The correct, idiomatic approach is to explicitly check whether findOne() returned null and, if so, throw a NotFoundException, ensuring the client receives a clear 404 response rather than a confusing null or empty response body. The Update operation combines a route parameter identifying which record to update with a request body (typically typed against an UpdateDto with optional fields) describing the changes. A common, efficient pattern uses the repository's update() method directly, which performs an UPDATE query without first loading the entity into memory, though many applications prefer first calling findOne() to confirm the record exists (throwing NotFoundException if not) before proceeding, especially when the response should include the fully updated entity. The Delete operation similarly combines a route parameter with the repository's delete() method, which returns a DeleteResult object indicating how many rows were affected. Checking this affected count (or, again, first calling findOne()) allows you to correctly return a 404 if the record didn't exist, rather than silently succeeding on an operation that effectively did nothing. Successful deletions commonly return a 204 No Content status with an empty response body, signaling that the operation succeeded but there is no meaningful data to return.

Practical example: API testing suites frequently target exactly these five endpoints as their first coverage target for any new resource, since they represent the most fundamental, must-work functionality of any data-driven feature.

Interview tip: @HttpCode() decorator overrides NestJS's default status code for a specific route, commonly used for 204 on DELETE.

Revision hook: Correct HTTP status codes, especially 201 for creation and 204 for deletion, are a small detail that significantly improves an API's professionalism.

NestJS CRUD TypeORM MCQs and Practice Questions

1. Which HTTP status code is most appropriate for a successful resource creation?

1. 200 OK
2. 201 Created
3. 204 No Content
4. 202 Accepted

Answer: B. 201 Created

Explanation: 201 Created is the conventional HTTP status code for a successful POST request that results in the creation of a new resource, distinguishing it from a simple 200 OK success.

Concept link: Standard CRUD mapping: POST (create, 201), GET (read, 200), GET/:id (read one, 200 or 404), PATCH/:id (update, 200 or 404), DELETE/:id (delete, 204 or 404).

Why this matters: A complete CRUD resource is really just five consistent, well-understood pieces working together: entity, DTOs, service, controller, and repository calls.

2. What should a service do if findOne() returns null when looking up a record by ID?

1. Return null silently
2. Throw a NotFoundException
3. Automatically create a new record
4. Ignore the error and continue

Answer: B. Throw a NotFoundException

Explanation: Explicitly throwing a NotFoundException when a lookup returns null ensures the client receives a clear, correctly-coded 404 response, rather than an ambiguous null or empty response body.

Concept link: Always explicitly handle the 'not found' case for single-record read, update, and delete operations.

Why this matters: Explicitly handling the 'not found' case is what separates a correct API from one that silently returns confusing or misleading responses.

3. What does the affected property on a TypeORM DeleteResult indicate?

1. The number of database connections used
2. The number of rows actually deleted by the operation
3. The time taken to execute the query
4. The ID of the deleted record

Answer: B. The number of rows actually deleted by the operation

Explanation: The affected property on a DeleteResult (or UpdateResult) indicates how many rows were actually affected by the operation, which is commonly checked to determine whether a targeted record actually existed.

Concept link: DeleteResult and UpdateResult objects contain an 'affected' count useful for detecting whether a target record existed.

Why this matters: Reusing methods like findOne() across update() and other operations keeps not-found handling logic consistent throughout a service.

4. Which HTTP status code is conventionally used for a successful DELETE request with no response body?

1. 200
2. 201
3. 204
4. 404

Answer: C. 204

Explanation: 204 No Content is the standard HTTP status code for a successful operation, like a delete, that intentionally returns no response body, since there is no remaining resource to describe.

Concept link: @HttpCode() decorator overrides NestJS's default status code for a specific route, commonly used for 204 on DELETE.

Why this matters: Correct HTTP status codes, especially 201 for creation and 204 for deletion, are a small detail that significantly improves an API's professionalism.

Common NestJS CRUD TypeORM Mistakes to Avoid

• Returning a plain 200 OK with an empty body for a delete operation instead of the more correct and conventional 204 No Content status.
• Forgetting to check for a null result from findOne() before using the value, causing runtime errors when a record doesn't exist.
• Using repository.update() but returning the original DTO to the client instead of fetching and returning the actually updated entity.
• Not converting route parameter strings (like id) to numbers before passing them to repository methods expecting a numeric ID.

NestJS CRUD TypeORM: Interview Notes and Exam Tips

• Standard CRUD mapping: POST (create, 201), GET (read, 200), GET/:id (read one, 200 or 404), PATCH/:id (update, 200 or 404), DELETE/:id (delete, 204 or 404).
• Always explicitly handle the 'not found' case for single-record read, update, and delete operations.
• DeleteResult and UpdateResult objects contain an 'affected' count useful for detecting whether a target record existed.
• @HttpCode() decorator overrides NestJS's default status code for a specific route, commonly used for 204 on DELETE.

Key NestJS CRUD TypeORM Takeaways

• A complete CRUD resource is really just five consistent, well-understood pieces working together: entity, DTOs, service, controller, and repository calls.
• Explicitly handling the 'not found' case is what separates a correct API from one that silently returns confusing or misleading responses.
• Reusing methods like findOne() across update() and other operations keeps not-found handling logic consistent throughout a service.
• Correct HTTP status codes, especially 201 for creation and 204 for deletion, are a small detail that significantly improves an API's professionalism.

NestJS CRUD TypeORM: Summary

A complete CRUD resource in NestJS combines everything covered so far: an entity describing the data shape, CreateDto and UpdateDto classes enforcing validation, a service using an injected TypeORM repository to implement create, findAll, findOne, update, and remove methods, and a controller exposing these through conventional REST routes. Correctly handling cases where a requested record doesn't exist, by throwing NotFoundException based on a null findOne() result or a zero affected count from update() or delete(), is what makes an API predictable and trustworthy. Following HTTP conventions closely, such as 201 Created for new resources and 204 No Content for successful deletions, rounds out a CRUD implementation that matches the shape of real, professional production APIs.