1. 오늘 겪은 문제
- nest-pipe(data-trans, data-validate middleware 비스무리 한거) handler-level, parameter-level, global-level
built-in pipe가 있어??
- postgres 사용기
- typeorm entityrepository 비활성화 개 살집기..ㅠㅠㅠㅠ
2. 해본 시도
- nest에서 pipe란 우리가 일전에 node에서 만들어 사용하였던 middleware와 유사하다. 데이터를 교환하는 시점에서 해당 데이터의 유효성을 확인한다거나 로그인 정보를 확인하는 것 처럼 요청과 응답 사이 혹은 시작과 끝에서 해당 작업들을 처리해 주는 도구들을 지칭한다.
- postgres와 pgadmin 그리고 typeorm을 설치 해준 뒤에, config파일에 postgres config를 정의해주고 해당 정보를 app.module에서 사용을 정의햄으로 사용할 수 있고, 해당 하는 db의 테이블들은 entity에서 정의해주면 된다
- nest-typeorm-postgres 환경에서 repository를 정의해주는 과정에서 0.2.0 버전 에서는 EntityRepository 데코레이터를 사용하여 쉽사리 커스텀 Repo를 정의해 줄 수 있었다. 하지만 0.3.0버전 이후로 해당 기능이 비활성화 됨에 따라서 repo를 하나의 서비스와 같은 구조로 생성하고, 해당 내용을 service에 DI 를 통해 사용하는 방법과, 직접 custom module및 repo를 생성하는 방법 두가지를 찾을 수 있었는데, 나는 후자를 통해서 해결하였다.
3. 해결 방법
- nest는 정의해놓은 도구들이 참 많다. pipe 도 그 중하나로 pipes폴더를 만들고 해당 폴더에 해당하는 pipe class의 파일을 정의한 후에, 사용하고 싶은 곳에 (주로 controller) @usePipes 데코레이터를 통해 사용 가능하다.
- 해당 시도들을 모두 해보고 여전히 Board entity를 찾을 수 없다는 오류가 발생하여 꽤 오래 삽질을 했고, 그 결과는 entity정의해주는 파일에서 @Entity 데코레이터를 빼먹고 있었다. 정말이지 어지럽다.
4. 새롭게 알게 된 점
- 전반적으로 nest는 node로 layered-architecture pattern을 구현해봤던 구조와 매우 유사하다. node에서는 유용한 도구들을 npm i 을 통해 수많은 도구들을 불러와 사용했다면, nest에는 기본적인 도구들이 대다수 내장되어 있어 편했다. 구조도 미리 정해두고 편한다.
- nest에서 각각의 모듈들이 서로 어떻게 상호작용하는 지를 파악하는 데에는 가장 외부의 app.module.ts 부터 연결된 각각의 모듈 정의 파일들로 점차적으로 살펴보는 것이 가장 빠르고 편한 방법 같다.
5. 오늘 더 효율적으로 일할 수 있었을 것 같은 방법은?