[TIL] 2023-1227 Nest.js 공부하는 중

Facts

• 사내에서 electron + Next.js 를 활용한 키오스크 POC 개발을 담당하게 되었음. POC 자체는 80% 정도 진행 되었다고 보여짐. 현재까진 여러 이슈가 있지만 일단 눈앞에 놓인 것을 하고 있음.
• 백엔드에도 관심을 가지게 되어서 TS 기반 프레임웤인  Nest.js를.. 노마드코더 강의 보면서 공부해보는 중.

Feelings

• 스타트업답게 회사에서 정말 많은 변화가 일어나고 있음. 그에 발맞춰 나도 변화해야겠다는 생각이 정말 많이 듬.
• 대표님과 사내 개발 문화에 대한 이야기를 나누다가, 문제의 본질 중 하나는 '서로 자유롭게 물어보기 힘든 분위기' 도 있음을 깨달음
• 예전에 팀플하면서도 느꼈던 부분이지만, 설령 실질적인 도움이 되는 이야기가 아니더라도 일단 자유롭게 이야기하고 받아줄 수 있는 분위기가 형성되어야 더 중요한 이야기들도 가감없이 오고갈 수 있다는 것을 다시금 깨닫게 되었음.
• 그리고 나 스스로에게 좀 자신이 없는 것 같은데 자신을 가져도 좋을 것 같다. 

Findings

• Nest.js 에서는 Controller 에서 라우트를 처리하고, 라우트의 실제 구현은 Service 를 통해서 이루어지도록 구조가 짜여져있음.
• 그리고 가장 상위 모듈에서 controllers 와 providers(주로 service) 를 등록하고 각 controller 에서는 service 를 주입받아서 사용함
• 직접 인스턴스를 생성하지 않고도 서비스를 참조할 수 있는 까닭은 Nest.js 프레임워크에서 이러한 의존성을 관리해주기 때문임.. 그래서 controller 클래스의 constructor 에서 이를 받아서 쓸 수 있다. 이렇게...

@Controller('movies')
export class MoviesController {
  constructor(private readonly moviesService: MoviesService) {}
...
}

• DI 의 장점은 인스턴스를 직접 생성하지 않아 느슨한 결합도를 가진다는 것임. 그리고 프레임워크에서 이러한 패턴으로 구현하도록 강제하고 있어 SRP에 맞는 단위로 코드를 분리할 수 있음.
• 느슨한 결합도를 가지면 당연히 변화에 대처하기 쉽고 코드의 변경 범위가 한정되기 때문에 유지보수가 쉽다는 것임.. 근데 지금으로썬 이게 어떻게 도움이 된다는 것인지 사실 잘 감이 오지 않는다. 어쨌든 그렇게 짜도록 강제되어 있다는 것이 이 프레임워크의 장점이라고 생각됨.
• Nest.js 에서는 데코레이터를 활용해 클래스, 메소드, 파라미터 등의 동작을 수정/확장하거나 메타데이터를 추가할 수 있음. 데코레이터가 Nest 의 기능인줄 알았는데 이는 타입스크립트의 실험적인 기능이고 그냥 이 프레임웤에서 이걸 적극 활용하는 것이었다. Nest.js 에서는 이 데코레이터를 활용해서 의존성 주입(@Injectable), 라우팅(@Get, @Post...), 유효성 검사(class-validator 활용) 등을 할 수 있음. 
• DTO 와 인터페이스의 차이는 뭘까?
  • DTO : Data Transfer Object 데이터 교환을 위해서 사용되는 것... 계층은 클라이언트 - 서버 일 수도 있고 또 서비스 계층 간의 교환일 수도 있음. 그러니깐 쉽게 생각하면 api 에서 교환되는 데이터의 형식
  • 엔티티 : 데이터베이스 테이블과 맵핑, DB 스키마를 반영하는 것. 같은 엔티티에 대해서도 어떤 목적이냐에 따라 DTO 를 바궈 응답해줄 수 있는 것.

Feedback

• 공부 시작하기 전에 로딩 시간이 너무 김... 나도 좀 효율적으로 빡! 하고 빡! 쉬고 싶은데 그게 잘 안되는게 고질적인 문제인 것 같다. 흠
• 키오스크 api 연동까지 마무리 되면 보기 좋게 코드 정리하는 작업을 좀 즐겁게 해야겠음.
• 네트워크, CS 쪽 지식이 필요해지는 순간이 옴... 출근 시간 활용해서 공부할 것.