서론 JWT를 구현하는 도중, 아래와 같은 에러가 발생했다. //회원가입 및 JWT TOKEN 발급 코드 async signup(signInDto: UserSigninDto) { const user = await this.userService.findById(signInDto.id); const exist = user != null; if (exist) { throw new BadRequestException('중복된 아이디 존재'); } else { const valiUser = new UserEntity(); const hashedPassword = this.hash(signInDto.pw); valiUser.id = signInDto.id; valiUser.pw = hashedPassword; co..

에러 메세지 원인 .env에 작성해 둔 JWT_SECRET이라는 이름의 환경변수를 읽는 과정에서 발생한 에러로 JWT 토큰 발행 시 반드시 secret key가 있어야 하는데 읽지를 못한 것으로 보인다. 공식 문서의 JWT 가이드 대로 따라하며 토큰 발급 시 발생했으며, 모듈에서 설정한 secret을 JwtModule에 등록하지 못했다. 환경변수를 읽어오기 전에 secret가 먼저 register되는 것 같아 보였다. @Module({ imports: [ UserModule, JwtModule.register({ global: true, secret: process.env.JWTSecret, signOptions: { expiresIn: '60s' }, }), TypeOrmModule.forFeature..

서론 지난 글과 이어서 작성해본다. [sendbird - 1]센드버드 chat의 사내 도입? api 사용해보기 / Next + Nest 서론 현재 근무하는 회사 서비스의 웹 소켓 기반의 채팅 기능이 전반적으로 하자가 많아서 카카오톡이나 다른 여러 채팅 API를 끌어다가 사용하자는 의견이 나오고 있고, 실제로 11월 초에 한번 mag1c.tistory.com 지난 글에서, 앞으로의 방향성에 대해 언급했는데, 추가된 부분이나 빠진 부분을 첨삭하여 요약해보았다. 1. 사내 채팅 기능과 맞물리는지 여부 (1:1 문의 기능 관점의 채팅만 필요한 상황) 2. 현재 회사의 비즈니스 로직을 무난히 적용할 수 있는가 (+ 채팅 봇 파악) 3. 백엔드 관점에서의 api 활용 센드버드의 1:1 채팅 기능 센드버드에는 아래처..

서론 현재 근무하는 회사 서비스의 웹 소켓 기반의 채팅 기능이 전반적으로 하자가 많아서 카카오톡이나 다른 여러 채팅 API를 끌어다가 사용하자는 의견이 나오고 있고, 실제로 11월 초에 한번 회의를 하기로했다. 그 중 센드버드를 채택할 것 같은 가능성이 짙어 센드버드를 사용해보고 장/단점들을 파악해보고자 한다. 대서사가 진행될 예정으로 센드버드의 간단한 API 사용 예제만 참고하고 싶은 분들은 5. 센드버드의 활용 부터 보시기 바랍니다. ★지적은 언제나 감사합니다★ 기존 문제점 현재 사내 서비스 내부의 웹 소켓 채팅은 크게 다음과 같은 문제점이 있다고 생각했다. 1. 미래를 생각하지 않고 단순 현 상황에서의 기능이 돌아가게만 작성되어 있다. 점차 적응하다보니 문제 하나가 터지면 여기저기 다 뜯어야했다. ..

서론 현재 간단하게 개발하고 싶은 것들을 실서버에 배포하고 계속해서 무언가를 적용해보려고 EC2 인스턴스를 통해 도메인을 등록, 배포 후 ALB를 적용시킨 상태이다. 모의투자, 웹소켓을 이용한 실시간 랜덤 데이터를 직접 만들고 투자할 수 있게 방향성을 잡고있는데, 우선 배포와 노드에 대한 적응이 먼저라 생각하여 간편한 계산기 애플리케이션을 만들었고 계속 여기에 무언가 해 나갈 생각이다. 각종 간편 계산기 모음 복리 계산기, 전역일 계산기, 기본 계산기 등 간단하게 사용할 수 있는 계산기를 제공합니다. mananaweb.net NGINX 502 에러 로그를 확인하고 싶은데, 단순 NGINX에는 에러로그가 남지 않아서 ALB 문제일 것이라 생각하여 S3 버킷에 로드밸런서 로그를 남겨놓은 상태이다. 과금때문에..

서론 서든어택 - 배틀그라운드를 거쳐 발로란트까지 나는 FPS를 무지하게 좋아했고 즐겨했었다. 좋아하던 게임을 놓고 개발에 흥미가 생겨 개발자가 되고, 개발 공부를 계속해서 막 하던 도중 즐겨 보는 코딩관련 유튜브 채널에서 옛날 향수를 느끼게 해주는 주제로 영상이 하나 게시되었다. 코딩애플님의 FPS - NetCode관련 영상 링크 모든 FPS의 대기 플레이가 불리하다는 것을 개발을 하면서 자연스럽게 깨닫게 되었는데, 서든어택을 할 당시만 해도 그런 정보들이 거의 전무해서 스나를 들고 있을때는 대기줌을 많이 했던 기억이 난다 ㅋㅋ 그 당시에는 잘하는 사람들의 플레이를 보고, 대회를 봐도 사실 피킹을 먼저하는 사람. 즉 대기스나보다 브레이킹을 거는 사람이 더 유리한 위치라는 것을 잘 인지하지 못했다. 그냥..

서론 노드로 전향한지 만 1개월이 되었다. 현재 근무하고 있는 곳의 애플리케이션 코드를 보면, 따로 예외처리를 해주는 부분이 없어 에러 핸들링과 에러 로깅 작업을 커스텀으로 진행하려고 한다. 이를 위해 공식 문서를 활용해가며 학습할 필요를 느껴서 공식문서에 해당 내용을 확인하고 학습해보자. NestJS의 예외 처리 Nest에는 애플리케이션 내에서 처리되지 않은 모든 예외를 처리하는 내장 예외 레이어가 존재한다. 애플리케이션 코드에서 예외 처리가 되지 않으면 예외 레이어에서 예외를 처리한다. 기본적으로 이 작업은 HttpException유형과 하위 클래스의 예외를 처리하는 내장 전역 예외 필터에 의해 수행된다. 예외를 인식할 수 없는 경우 다음과 같은 500에러를 내보낸다. { "statusCode": 5..

에러 발생 경위 도커라이징하여 EC2 인스턴스로 배포를 계속 시도해보다가, 용량문제로 아래와 같은 에러가 발생했다. failed to register layer: write /usr/src/app/node_modules/sockjs/Changelog: no space left on device 단순 인스턴스의 공간 문제인 것 같아 아래 명령어를 통해 디스크 용량을 확인해보았다. $ df -h 용량을 거의 다 차지하고 있는 것 같아서, 도커 이미지를 여러번 등록하기만 했지 삭제하지 않았던 것이 생각나서 확인해보았더니 이미지가 엄청 많았다. 하나하나 일일이 IMAGE ID로 지워주기 힘들 것 같아 태그네임이 인 모든 이미지파일을 지우는 명령어를 알려달라고 GPT에게 부탁했더니 아래 명령어를 던져주었고, 실행..