2회차 익명 게시판 서비스 [에러 및 부족한 개념 채우기]

 

1.  port: +process.env.PORT  에서  환경 변수 안되는데 질문  process.env.PORT  3306 에서 string 형식은 number형식에 할당할수 없다는에러.

 

=>  1.  const port = parseInt(process.env.PORT, 10); // 10진수로 파싱하여 숫자로 변환

      2.  const port = +process.env.PORT;

 

 

 

2. 컨트롤러 구성시 Get이 먼저 나와야 하는 이유

NestJS의 데코레이터(decorator)의 우선순위는 라우팅 매칭과 미들웨어 실행에 영향을 미친다.

NestJS는 데코레이터의 우선순위를 기준으로 요청을 올바른 핸들러 함수로 라우팅하고, 미들웨어를 실행한다.

1. 경로 매칭 우선순위:
   • NestJS에서 경로 매칭은 가장 구체적인 경로와 HTTP 메서드에 가장 높은 우선순위를 부여한다.
   • 경로가 더 구체적인 데코레이터는 상위에 배치되어야 한다. 예를 들어, /users/:id와 /users/profile 경로가 있다면 /users/profile 경로를 처리하는 데코레이터가 먼저 나와야 한다.
   • 경로에 매칭되는 핸들러 함수가 여러 개 있는 경우, 가장 먼저 일치하는 핸들러 함수가 실행된다.
2. HTTP 메서드 매칭 우선순위:
   • HTTP 메서드에 따라 데코레이터의 우선순위가 있다. 일반적으로 @Get()이나 @Post()와 같은 HTTP 메서드 데코레이터가 가장 높은 우선순위를 가지며, 나머지 HTTP 메서드 데코레이터는 그보다 아래에 배치되어야 한다.
   • 같은 경로에 여러 개의 HTTP 메서드 데코레이터가 존재하는 경우, 해당 경로의 요청에 가장 먼저 매칭되는 데코레이터에 해당하는 핸들러 함수가 실행된다.
3. 미들웨어 우선순위:
   • NestJS의 미들웨어는 @UseGuards(), @UseInterceptors(), @UseFilters()와 같은 데코레이터를 통해 설정된다.
   • 미들웨어 데코레이터의 우선순위는 상위에서 하위로 내려가는 순서이다. 즉, 상위에 위치한 미들웨어 데코레이터가 먼저 실행된다.
   • 미들웨어는 요청을 가로채고 수정하거나 검증하는 등의 작업을 수행할 수 있다. 따라서 미들웨어의 순서는 중요하며, 요청 처리 파이프라인에서 원하는 동작을 보장하기 위해 적절한 우선순위를 유지해야 한다.

 

3. 컨트롤러에서 ValidationPipe 사용 

 

search(@Param('title') params: SearchTitleDto)


search(@Param() params: SearchTitleDto)

처음 첫번째 처럼 코드를 작성했지만 유효성 검사가 되지 않아 아래와 같이 수정하였다.

 

@Param('title') 데코레이터는 title 경로 파라미터의 값을 params 변수에 직접 할당한다.

이 경우에는 params 객체가 아니라 title이 DTO(SearchTitleDto)의 인스턴스에 할당되어서  유효성 체크가 되지 않았다.

 

4.Promise<Post>같은 반환 형에 대한 이해 부족

우선 반환형이 Promise인 이유는 async await를 사용해서 Pomise로 반환이 되며 Post라는 객체의 배열로 받기 때문이다.

여기서 Post는  생성자에서 선언한 DB에서 주입받은 post entity 객체이다.

  constructor(

    @InjectRepository(Post)

    private postRepository: Repository<Post>,

  ) {}

 

• @InjectRepository(Post) : @InjectRepository() 데코레이터는 TypeORM에서 제공하는 데코레이터로, Repository 인스턴스를 주입받을 때 사용된다. Post는 Entity(데이터베이스 테이블에 매핑되는 클래스)를 나타낸다. 이 데코레이터를 사용하여 postRepository에 Repository<Post> 인스턴스를 주입한다.
• private postRepository: Repository<Post> : 클래스 내부의 postRepository 멤버 변수를 선언하고, Repository<Post> 타입의 인스턴스를 할당한다. 이를 통해 postRepository를 클래스의 다른 메서드에서 사용할 수 있게 된다.

이렇게 의존성 주입을 사용하면 클래스의 생성자를 통해 외부에서 필요한 의존성을 주입할 수 있다. 이는 코드의 유연성과 재사용성을 높여주며, 테스트와 모듈화를 용이하게 한다. @InjectRepository() 데코레이터를 사용하여 TypeORM의 Repository 인스턴스를 주입받을 수 있으며, 해당 Repository를 통해 데이터베이스와 상호작용할 수 있다.

 

 

 

지금 까지 반환형을 적어주지 않고 개발을 하였는데 큰 문제가 없었다. 

이는 TypeScript의 타입 추론 기능을 통해 메서드의 반환형이 자동으로 추론되기 때문이었다.

 

그러나 명시적인 반환형을 선언하는 것은 코드의 가독성을 높이고 개발자와 동료들이 코드를 이해하기 쉽게 해준다.

또한, TypeScript는 명시적인 반환형을 통해 타입 체크를 보다 엄격하게 할 수 있어서 잠재적인 버그를 미리 방지하는 데 도움이 된다.  

 

즉 , 이런 이유에서 nestjs에서 typescript를 사용하므로 거의 무조건 적으로 반환형을 적어주도록 하자 !

 

await async와 반환형의 Promise 개념에 대해 아래 링크를 참조 하자 @!

• https://jojoldu.tistory.com/699
• https://velog.io/@giwan_dev/mistake-with-async-await
• https://eslint.org/docs/latest/rules/no-return-await

 

현재도 왜 컨트롤러에서의 반형환은 Promise<Post>로하면 안되는지 이해가 안되어 그냥 뺴놓았다.

또한 반환형을 적으면 타입으로 사용되었따고 하는데 차후 깊게 공부할때 이해해보자..