
때는 사이드 프로젝트에서 파일 업로드 API를 구현하기 위해 attachment 테이블을 설계하고 있을 때였다.다른 테이블들의 경우엔 PK를 auto_increment를 통해 자동으로 고유한 값을 갖도록 했었는데, File Upload의 경우엔 직접 pk키의 값을 지정
이전에 진행하던 프로젝트가 슬슬 배포를 준비하는 단계에서의 일이었다. 메모리가 부족해서 EC2가 계속 터져버리는 일이 있었는데 어떻게 해결했는지에 대해서 기록해본다.때는 프로젝트의 배포 단계를 준비할때 일어났다. 당연히 production 환경 서버에 코드 변경 사항을
때는 API 서버의 http --> https 전환 이후 였다.1:1 실시간 채팅을 위해서 Socket.io 라이브러리를 이용해 WebSocket 서버를 열었었는데 WS 연결은 잘됐지만 WSS 연결은 되지 않았다.프론트 서버 또한 HTTPS 설정이 되어 있었기 때문에

메인 프로젝트할 때의 이야기다. 발단 당시 나는 Transaction 이라는 개념 자체를 모르던 시절이었다. 그러다 같이 사이드 프로젝트를 하는 선배가 Transaction 이라는 키워드를 던져주셔서 이에 대해서 공부를 하고 동아리에서 매 2주마다 하는 발표(당시 영상

사이드 프로젝트를 할 때의 이야기이다.난 GitHub Actions와 Docker를 이용해서 CI/CD를 구축했었다.여느날처럼 작업 사항을 develop branch에 병합하고 있었는데, Build 과정에서 에러가 발생하는 것이 아닌가?'엥?? 분명 내 로컬 환경에서는

글 작성 당일에 있었던 따끈따끈한 이슈였다.기존의 맥북이 맛이 가서 새로운 노트북에 프로젝트 환경을 구성하는 중이었는데(이 글 주제에 국한하면 Local DB) DB migration을 하는 도중 사건이 발생했다.로컬 환경의 DB에 TypeORM의 migration을

제목은 거창해 보이지만 사실 단순 ValidationPipe의 option을 재정의할 수 있는 CustomValidationPipe이다.사이드 프로젝트에서 파일 업로드 API를 구현할 때의 이야기이다.File Upload API를 구현하면서 생긴 일 (feat. TSI

평화롭게 프로젝트를 진행하고 있었고 고차 함수를 사용하면서 문제가 발생했다.DB에서 가져온 영속성 객체를 Domain Entity로 변환하면서 에러가 발생했다.TypeError가 발생한다.순간 뭐지? 싶어서 의존성 주입이 제대로 안됐나? 싶어서 각 Mapper 클래스를