24/10/28 월 업무 TIL

오랜만에 업무 TIL을 작성한다.

본격적으로 팀장님께서 미리 푸쉬해주신 모듈(쉽게말해 폴더, msa 구조에서 모듈끼리는 침범하지 않는 것이 원칙!) 구조에 따라 채팅 모듈을 서비스별로 나누어보았다. 

 

결론적으로 이번에 바뀌는 HTTP 통신의 경우 

1) ex. A 엔티티가 B 엔티티를 참조하는 경우 FK 사용하지 않기 위해 HTTP로 서로 통신하는 것. 

기존 이 두 엔티티의 FK 연관관계가 끊기는 것이 MSA이다. 

 

2) apps 하위에 들어오는 것들은 api(여러가지), batch(1개의 파일로 관리), handler, entity,service,controller,repository 

기존에 libs 하위에 data 관련의 디렉토리를 넣었는데 이제 이것은 apps 하위로 다 이동하고 libs에는 각 모듈 간의 '공통 정보'만 들어가게 되었다. 

 

3) event의 경우 batch로 쏘게 되는데, 이것은 1개의 파일로 관리하고 kafka를 이용해서 event를 Emit 하게 된다. 

-> 여기서 event란, 주기적으로 업데이트 되는 데이터들 (@Cron 등) 

 

4) MSA 구조의 같은 모듈 내의 1 파일의 엔티티들끼리는 @OneToOne 등 연관관계 설정이 가능하다. 

그러나 다른 모듈의 엔티티들과는 연관관계를 잡을 수 없다. 

 

5) index.ts 파일은 모듈 import를 하게 되면 만약 3개의 import를 한 파일에 정리해줌으로써 다른 파일에서는 1줄의 import문만 나오기 때문에 가독성이 좋다. 

 

6) Data Life Cycle 

나는 기존에 라이프 사이클이라고 하면 Java의 생명주기와 같은 프레임워크의 생명주기만 알고 있었다. 

오늘 배운 것은 데이터에도 라이프사이클이 있다는 것이었고, 데이터에 대한 시작~소멸의 과정이 담긴다.

생성 및 수집 > 저장 및 관리 > 사용 및 공유 > 보관 > 파기 --> 아직은 개념이 잘 와닿지 않아 좀 더 봐야한다. 

* NestJS의 생명주기는 onModuleInit ~ onModuleDestory다. 

 

7) .module 파일 내의 forFeature 등 DB 설정

이전에 module 파일에서 보았던 forFeature의 단어의 의미를 잘 모르고 그냥 따라썼다. 

TypeORM에서는 forRoot, forFeature, forRootAsync 

- forRoot : DB연결을 위한 기본 설정으로 애플리케이션에 DB를 전역적으로 설치한다. 

앱의 루트 모듈 AppModule에서만 사용 

- forFeature : 특정 모듈에서만 사용할 엔티티 레포지터리를 가져올 때 사용 

- forRootAsync : 비동기 방식으로 DB 연결 설정 

 

8) useFactory와 configService 

useFactory: (configService: ConfigService) => {

 

module 파일들을 보면 useFactory를 통해 의존성 주입을 해주는 것을 계속 보았다.

이전에 useFactory라는 단어를 알고는 있었지만, 그 의미는 몰랐다. 

위의 구문 의미는 의존성 주입을 활용한 비동기 설정 로직을 정의하는 방식으로 configService는 NestJS에서 제공하는 서비스로 환경변수나 설정값을 관리하기 위해 사용된다. 

 

if, 내가 내 로컬에서 서버를 띄우기 위해 .env 환경변수 파일을 변경했다고 치자. 

변경된 .env 파일을 NestJS의 configService가 읽는데, 여기서 configService.get() 구문이 나온다면, 이를 호출할 때 '최신 값'을 가져오므로 내가 로컬 .env 환경변수 파일에서 변경한 내용이 반영되어 읽힌다. 

 

오늘 나의 부족했던 개념들이 조금이나마 더 채워지는 날이었다. 질문도 많이 하고, 공부도 더 많이 하자! 

끝나는 그날까지 후회없도록 :)