문제상황 TDD 방법론을 따라 프로젝트를 진행하려는데 Jest를 이용하여 test 코드를 작성하던 중, 한가지 문제를 마주한다. test를 위한 DB는 그 조건에 따라 생성되고 삭제되어지는 특성상, 실제 개발환경에서의 DB와 test DB를 분리하기 위해서 local DB는 2가지로 나누어 세팅을 해야한다. 그런데 test를 실행할때마다 typeORM 세팅의 연결값을 매번 변경해줘야하는 문제가 상당히 번거로웠다. 고민하던 와중, cross-env라는 npm package를 알게되었고 이를 이용하여 상황에 따라 dotenv 설정값을 유동적으로 활용할 수 있도록 세팅을 구상해보았다. 요약. JEST의 test파일 실행시 기존 DB를 사용함으로 인한 DB내부 데이터 오염문제 test용 DB 분리로 해결 test용 DB 분리 이후, npm run 실행 환경(dev, test, production)에 따른 DB 설정문제 개발간 서버를 돌릴때, test코드를 돌릴때마다 dev.

문제상황 Failure 에러핸들링 중, 에러메세지를 response로 보내려고 한다. 이에 return을 사용 에러가 나와야 할 상황에서 정상적으로 에러메세지를 response로 보낸다. 하지만 에러코드를 알려야 할 status code는 정상을 알리며 이후 모든 함수와 명령이 진행됨 해결 Success return이 아닌 throw를 사용하여야 한다. 특히 node.js에서 서버를 돌릴때, 단순히 return만으로는 이후의 모든 과정, 즉 controller - service - dao 등에서 return을 한 함수 이외 모든 명령어가 진행 된다. 하지만 throw의 경우, 에러를 내보내는 것 뿐만 아니라 이후의 모든 명령어를 중지시킨다.

에러 상황 TypeScript로 typeORM을 세팅할때, dotEnv로 설정값을 주고 연결을 해보면 다음과 같은 오류를 볼 수 있다. 위 3개의 해당 error message를 살펴보면 차례로 다음과 같다. TS2322: Type 'string' is not assignable to type '"mysql" | "mariadb" | "postgres" | "cockroachdb" | "sqlite" | "mssql" | "sap" | "oracle" | "cordova" | "nativescript" | "react-native" | "sqljs" | "mongodb" | "aurora-mysql" | ... 4 more ... | "spanner"'. TS2322: Type 'string' is not assignable to type 'number'.

nestJS - cli 설치 사전 조건 : node lts버전 설치 npm i @nestjs/cli 또는 npm i -g @nestjs/cli 이렇게 package.json 파일에서 정상적으로 설치되었음을 확인할 수 있다. nestJS - new Project 시작하기 nest new <new project name> // 예시 nest new nestjs-test 위와 같이 입력하면 현재 터미널이 위치한 폴더 내에 새로운 “nestjs-test"폴더가 만들어지면서 그 안에 세팅이 된다. 만약 $ mkdir nestjs-test 로 폴더를 만들고 이 위치에서 진행중이라면, nest new ./ 위와 같이 입력시 현재 폴더명 그대로 새로운 프로젝트가 진행된다.

youtube 서핑을 하다 우연히 보게 된 영상. “부트캠프 가셔도 실패하는 분 특징” 문구가 굉장히 도발적이었다. 마침 부트캠프를 막 수료한지라 더욱 내 시선을 끌었었다.   youtube 내용 요약 - 펼치기 youtube 내용 요약 글쓰기를 잘하는 사람이 개발자로서도 잘한다. 본인의 메세지를 글에 녹일 수 있어야 한다. 컴퓨터가 이해할 수 있는 코드는 어느 바보라도 작성할 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 작성한다. 마틴 파울러, 리팩토링의 저자 코딩 자체가 문서를 정리하는 것이다.

AWS EC2에서 백엔드 서버와 프론트엔드 서버를 돌리는 와중, 백엔드 서버의 PM2 리스트 전체가 다운이 되면서 멈추는 일이 발생했다. 이래저래 복구를 하다가, 프리티어 t2의 메모리 부족 현상때문이라는 결론에 다달았고 ec2를 재부팅하였다. AWS 퍼블릭 IP 주소가 바뀌었다? EC2 재부팅 결과, 서버의 퍼블릭 IPv4 주소가 바뀌는 일이 발생했다. 왜 그런가 찾아보니 AWS 기술문서에 다음과 같은 안내가 있었다. 퍼블릭 IP 주소1 다음과 같은 경우 인스턴스의 퍼블릭 IP 주소가 변경됩니다. 중지되었거나 최대 절전 모드로 전환된 인스턴스는 다시 시작될 때 새 퍼블릭 IP 주소를 받습니다.