기존의 NestJs + TypeORM 조합에서 NestJs + Prisma 도입을 위해 MVP 프로젝트에 적용하는 과정에서 위처럼 원격 환경에 배포시 빌드 과정에서 TS 컴파일 관련 에러가 발생하면서 node_modules 내부에 위치한 prisma client에 Schema Property가 없다는 에러가 발생하였다. 해당 에러가 로컬 환경의 빌드에서는 발생되지 않고, 해당 원격 환경에서 빌드시 발생하고 있었는데 해당 에러와 관련된 스택 오버플로우, 깃헙 이슈를 찾아보면 하나같이 "IDE를 재시작해라"와 같은 로컬 환경에서의 이슈에 대한 답변만 존재하였다. 현재 사용하고 있던 배포 플로우는 다음과 같았다. 원격 저장소의 지정된 브랜치에서 git pull yarn install rimraf로 기존 dis..
NestJS에서 Queue를 사용하는 방식에는 대표적으로 Bull을 통한 Redis, aws-sdk를 통한 AWS SQS(Simple Queue Service) 등이 있다. 공식문서 레시피에서는 Queue를 사용 시Redis/Bull를 사용하는 것을 권장하고 있다. 여기서 Redis는 뭔지 알겠는데 Bull이 뭔지 모르겠다고 생각이 들수도 있다. 잠시 Bull이 뭔지 알아보자. Bull Github 주소에 들어가면 ReadMe 소개에 아래와 같이 적혀있다. The fastest, most reliable, Redis-based queue for Node. Carefully written for rock solid stability and atomicity. 소개글을 그대로 확인해보면 Bull은 Node ..
회사내에서 프로젝트를 진행할 때는 대부분 NestJS, TypeORM, RestAPI를 기본 스펙으로 잡고 진행하는데 외부에서 진행되던 프로젝트가 NestJS, TypeORM에 Liquibase 라는 처음 접하는 데이터베이스 버전 관리 툴을 사용하였는데 내부로 인수인계가 다 되진 않은 상태에서 local 환경에서 개발하다 $ npm run start:dev를 했는데 정상적인 상황이라면 아래처럼 서버가 실행되어야 정상이다. >>> liquibase update start 뒤에 liquibase가 실행된다는 로그가 남아있는 채로 update end 로그가 뜨지 않고, 3 ~ 4분 뒤에 Caused by: liquibase.exception.LockException: Could not acquire chang..
유저 동시 접속 방지 기능을 개발이 완료된 서비스에 추가하는 방식으로 구현해야될 일이 생겼다. 해당 서비스의 경우, 로그인, 유저 관리를 세션/쿠키 방식이 아닌 JWT 방식으로 관리하고 있었기 때문에 동시 접속 방지를 websocket을 활용하여 구현하였다. 대략 어떻게 동시접속 방지를 구현할지에 대해 생각해보면 순서가 다음처럼 되었다. 유저가 로그인할 때, 토큰을 프론트로 전송함과 동시에 socket connection을 연다. 해당 유저가 로그아웃 할때까지 connection을 유지한다. 다른 클라이언트에서 해당 유저가 접속하면 기존의 connection을 끊고, 새로 접속된 클라이언트에서만 로그인시킨다. 위와 같은 방식으로 큰 틀을 잡고 구현하였다. 기존의 사용하던 NestJS가 v7이고 socke..
개발/NestJS 2023. 5. 29. 23:59
기존의 NestJs + TypeORM 조합에서 NestJs + Prisma 도입을 위해 MVP 프로젝트에 적용하는 과정에서 위처럼 원격 환경에 배포시 빌드 과정에서 TS 컴파일 관련 에러가 발생하면서 node_modules 내부에 위치한 prisma client에 Schema Property가 없다는 에러가 발생하였다. 해당 에러가 로컬 환경의 빌드에서는 발생되지 않고, 해당 원격 환경에서 빌드시 발생하고 있었는데 해당 에러와 관련된 스택 오버플로우, 깃헙 이슈를 찾아보면 하나같이 "IDE를 재시작해라"와 같은 로컬 환경에서의 이슈에 대한 답변만 존재하였다. 현재 사용하고 있던 배포 플로우는 다음과 같았다. 원격 저장소의 지정된 브랜치에서 git pull yarn install rimraf로 기존 dis..
개발/NestJS 2023. 4. 17. 08:20
NestJS에서 Queue를 사용하는 방식에는 대표적으로 Bull을 통한 Redis, aws-sdk를 통한 AWS SQS(Simple Queue Service) 등이 있다. 공식문서 레시피에서는 Queue를 사용 시Redis/Bull를 사용하는 것을 권장하고 있다. 여기서 Redis는 뭔지 알겠는데 Bull이 뭔지 모르겠다고 생각이 들수도 있다. 잠시 Bull이 뭔지 알아보자. Bull Github 주소에 들어가면 ReadMe 소개에 아래와 같이 적혀있다. The fastest, most reliable, Redis-based queue for Node. Carefully written for rock solid stability and atomicity. 소개글을 그대로 확인해보면 Bull은 Node ..
개발/NestJS 2022. 9. 29. 08:20
회사내에서 프로젝트를 진행할 때는 대부분 NestJS, TypeORM, RestAPI를 기본 스펙으로 잡고 진행하는데 외부에서 진행되던 프로젝트가 NestJS, TypeORM에 Liquibase 라는 처음 접하는 데이터베이스 버전 관리 툴을 사용하였는데 내부로 인수인계가 다 되진 않은 상태에서 local 환경에서 개발하다 $ npm run start:dev를 했는데 정상적인 상황이라면 아래처럼 서버가 실행되어야 정상이다. >>> liquibase update start 뒤에 liquibase가 실행된다는 로그가 남아있는 채로 update end 로그가 뜨지 않고, 3 ~ 4분 뒤에 Caused by: liquibase.exception.LockException: Could not acquire chang..
개발/NestJS 2022. 3. 24. 08:20
유저 동시 접속 방지 기능을 개발이 완료된 서비스에 추가하는 방식으로 구현해야될 일이 생겼다. 해당 서비스의 경우, 로그인, 유저 관리를 세션/쿠키 방식이 아닌 JWT 방식으로 관리하고 있었기 때문에 동시 접속 방지를 websocket을 활용하여 구현하였다. 대략 어떻게 동시접속 방지를 구현할지에 대해 생각해보면 순서가 다음처럼 되었다. 유저가 로그인할 때, 토큰을 프론트로 전송함과 동시에 socket connection을 연다. 해당 유저가 로그아웃 할때까지 connection을 유지한다. 다른 클라이언트에서 해당 유저가 접속하면 기존의 connection을 끊고, 새로 접속된 클라이언트에서만 로그인시킨다. 위와 같은 방식으로 큰 틀을 잡고 구현하였다. 기존의 사용하던 NestJS가 v7이고 socke..