NestJS에서 파일들은,
App module - module - controller - service 의 구조를 가지고 있는 것 같다.
module은 각각 자신과 관련된 controller와 service를 import하여 가지고 있는데, 일반적으로 controller에서 service를 import하여 응답을 처리하는 것 같다. 여기서 controller와 service를 분리하는 이유는 service에서 실질적인 비즈니스 로직을 담당하고 controller에서는 url을 분리하는, 음 아마도 route를 분리하는 역할을 담당하는 게 아닐까 싶다.
NestJS는 express.js와 fastify 위에서 돌아가는 프레임워크라고 들었는데, 룰이 정해져있지 않은 express 위에서 사람들이 가장 대중적으로 사용하던 컨벤션이 아니었을까.
Module
movie.module.ts
module에서는 각각의 controller와 service 파일을 import한다.
이 module은 더 상위 module에서 import되어 module간의 계층 구조를 이루게 된다.
Controller
controller에서는 API URL를 관리한다.
line 14를 보면 @Controller('movies')라고 적인 Decorator가 보인다.
이 module은 domain 뒤에 movies라는 path로 시작하는 API 요청을 관리한다는 것을 알려준다.
그 아래에서는 @Get(), @Delete()와 같은 Decorator를 통해 API 요청에 대한 Method와 URL을 관리하고 있다.
Method를 담당하는 Decorator 밑에 붙는 함수명은 임의로 작성해도 된다.
이 controller는 함수 내에서 직접 로직을 작성하지 않고,moviesService라는 파일을 import해서 요청에 대한 응답을 보낼 때 활용하고 있는 것을 볼 수 있다. 이는 controller가 URL의 분기점 역할만 수행할 수 있도록 권장하는 NestJS의 컨벤션을 따르고 있기 때문이다.
Service
service 파일에서는 실질적인 비즈니스 로직을 작성한다. 현재는 공부중이라서 아직 DB에 연결되어 있지 않아서, class 내에 배열을 임시로 만들어 연습하고 있는 모습이다.
Entity
Entity라고 부르던데 DB Schema에 대한 type을 담는 역할을 하는 것 같다. 지금은 임시로 만든 배열에 대한 entity를 만들었다.
DTO
DTO는 Data Transfer Object로 데이터 교환에 사용되는 객체 모델이라고 한다. NestJS에서는 단순히 type을 지정해주는 것이 아니라 유효성 검사와 같이 개발자의 입장에서 불편한 점들을 편리하게 만들어준다.
예를 들어class-validator라는 package를 설치하여, @IsString과 같은 Decorator를 사용하면 string에 대한 유효성 검사를 할 수 있다.
