내가 보려고 만듬

문제스웨거를 설치하고 세팅한 뒤 localhost 에서는 정상적으로 스웨거가 확인되나, 배포한 서버에서는 정상적으로 스웨거가 확인되지 않고 SwaggerUIBundle is not defined 오류가 확인되었다.  해결 방법 SwaggerModule.setup('api/docs', app, document, { swaggerOptions: { persistAuthorization: true, }, customSiteTitle: 'API Docs', customfavIcon: '/favicon.ico', customJs: [ 'https://cdnjs.cloudflare.com/ajax/libs/swagger-ui/4.15.5/swagger-ui-bundle...

계기개인프로젝트를 진행하면서 이메일 암/복호화를 구현하던 중, 문득 무언가 불편함을 느꼈다. 결국 이메일을 암호화해서 저장하게 되면, 이메일을 조회할 때 이메일을 암호화해서 조회, 그리고 조회한 뒤에 클라이언트에게 보여질 땐 복호화되어야 하기 때문에 이메일을 클라이언트에게 보여주기 위해서는 동일 로직을 여러번 거쳐야 했다.  인증 / 인가를 별도로 매번 구현하는 것이 아니라 UseGuards나 UseInterceptors 데코레이터를 통해 관심사를 분리하는 것처럼 db에 접근할 때 항상 prisma를 통해 접근하기 때문에 prisma 에서 email 필드에 대해 암/복호화 과정을 거치는 부분을 세팅한다면 암/복호화를 놓치는 휴먼이슈나 가독성 등 여러 측면에서 괜찮을 것 같다는 생각이 들었다.   과정처음..

문제점 현재 디폴트로 만들어둔 ami 이미지를 통해 private 인스턴스를 오토스케일링하고 있고, 배포시 다음과 같은 과정중에 있다.  - 소스코드 github push- Jenkins에서 ssh 스크립트로 Bastion Host 접속- Bastion에서 각각의 ssh 스크립트로 Private Host 접속- 각각의 Private에서 소스코드 git pull 후 서버 실행 스크립트~~   그리고 aws에서는 서버가 죽게 되면 이를 체크하고 만들어둔 ami 이미지를 그대로 새로운 인스턴스로 복각하여 aws에 입력해둔 명령어를 포함해서 작동하면서 서버가 열리게 되어 정상적으로 오토스케일링은 가동되고 있다.  문제는 배포시에 ssh스크립트로 직접 bastion에서 private로 접근할 때 ip주소를 알아야..

발단프로젝트 중 핸드폰에 저장된 주소록을 서버로 전송하여 차단된 유저를 확인하고 동작을 구분해야 했다.차단된 번호는 카운트, 차단되지 않은 번호는 db에 저장하도록 해야 하는데, 사람마다 차단하게 될 번호의 갯수는 제각각이다.  연락처가 100개도 안될 수도 있지만, 10000개가 넘는다던지 하는 경우에 어디까지 저장되었고, 어디부터 다시 저장해야 하는가 하는 그런 동작이 필요했다.  구현 중에 문득 조회하는 시간복잡도에 대한 고민이 생겼다. 배열을 그대로 돌리면 중복값에 대한 불필요한 검사가 반복되기 때문이다. 그래서 이전에 공부했던 Set에 대해 다시 공부하면서 처리한 과정을 써보려 한다.  해결과정 const startSet = performance.now(); // Set 자료구조를 사용..

이전 포스트에서 에러처리를 하면서 확인했듯.. 회원 / 비회원 유무를 조회하는데 POST로 하고 있어 자세히 살펴보니, 주민등록번호 앞자리를 받는데, 해쉬해서 저장하고 있었다. 그래서 이 부분은 body로 값을 넘기는 것에 대해 의도가 있기에 넘어가긴 하는데, 다른 부분에서 어차피 다듬어야 할 것들이 너무나도 많아서.. 당장 실질적으로 코드를 고칠 수 없어 포스팅만 하고자 한다. 먼저 SQL인젝션 대비 안되어 있는 부분... 기존 포스팅에서 다뤘으니 넘어가자.. // * 회원/비회원 유무 const isUser = async (isUserDto: IsUserDto) => { const hashedResidentNumber = await cipherFuc(isUserDto.resident_number); ..

엘리스에서 교육을 받는 과정에서 배운 것은 아니지만, 코치님께서 코드리뷰를 해주시는 과정에서 세심하게 에러처리에 대한 부분을 놓치지 않고 똑같은 로직 상관없이 대부분 체크해주셨다. 당시 프론트에서 어지간한 검증은 해서 넘어올 것이라는 안일한 생각이 있었는데, 그렇다고 한들 에러처리는 당연한 것이지만 해서 나쁠 것이 없기에 최대한 하는 것이 좋겠다고 생각했었다. 추가로는 나중에 입사해서 내가 직접 api를 설계, 구현하고 테스트하는 과정에 있다면.. '답답하고 오래걸리더라도 뭘 해도 다 안되다가 가능할 때만 db에 전송해야겠다. '정도는 생각했던 것 같다. 이번에 회사에 입사해서 회사코드들을 보며 숨이 막히는 상황들이 참 많은데, 여러모로 코치님께 배운 여러가지에 대해 감사함을 마구마구 느끼고 있다...!..

서두 이번에 입사하면서 회사 코드를 확인했는데 여러모로 쉽지 않았다. 왜 nest가 인기가 많은지 새삼 체감하는게, express가 워낙 자유도가 높다고는 하지만, 변수명 빼고는 모든 부분이 들여다봐야 이해가 가능했다. 이미 전 포스트에서 sql인젝션에 대비하지 않고 쿼리문에 직접 변수를 넣는 것부터 어느정도 나의 포지션에 대해 직감하고 있는 중이다...ㅎㅎ 당장 api를 수정해서 적용해야 하는 일이 있었는데, 소통하면서 개발하는 단계면 상관없는데 테스트하자마자 바로 서버에 적용을 해야하는 상황이라서 에러처리를 확실히 해야하는데 이미 구현되어있던 api들을 보았을 때 에러처리가 명확하지 않은 부분들이 있기도 했고, 설명하긴 너무 길어지고.. db관련 에러를 throw하지 않고 컨트롤러로 옮기는 등.. 방..

처음에 각 컴포넌트별로 페이지를 구성해서 대충 기능만 구현을 하고 배포에 중점을 두려 계획했다. 처음 계획할 당시 서비스 자체(백킹트랙 생성)는 프론트에 대부분의 로직이 있다보니 얼른 구현해서 목적달성 방향으로 달리다가.. 욕심이 생기기 시작했다. 이것저것 기능들을 추가하다보니 본질과 멀어지면서...ㅋㅋ 일이 커졌다. 서버를 열어 실질적으로 운영하는 경험을 목표로 하지만, 기존에 당연시하게 있는 기능들을 다 넣어야 경험이 경험다워질 것 같아서 제대로 갖추고, 목표를 잡고 작업을 해야겠다고 생각을 했다. 그래서 프론트쪽도 구조도를 갖춰보았다. 싱글페이지로 컴포넌트를 차례로 내려서 보여주고, 각 기능들은 좌우에 기획한 것들을 담았다. 지금까지 서버쪽은 기본적인 auth와 만들어진 백킹트랙 코드 데이터, 포스..

생각해보니 시퀀스다이어그램을 만들어놓고 블로그에 포스팅을 안했다는걸 뒤늦게 알아서 기록겸 하나만 올려보려 한다. 솔직하게는 처음에는 이정도로 계획하지 않았는데, 레디스를 추가하게 되면서 조금 변경된 내용은 있지만, 그래도 큰 틀 안에서는 구상한 계획과 크게 벗어나지는 않은 것 같다. 사실 프론트쪽은 구상한 것과 달라진 부분이 꽤 많은데, 서버쪽은 그럴 일이 거의 없는 것 같다. 아무래도 내가 혼자 작업하는 것이다보니 프론트로 넘겨주는 데이터를 수정하는 내용들은 조금 있긴 하지만 대부분은 그대로 가게 되어 뿌듯하고, 왜 필요한지 피부로 와닿는 것 같다. 로그인 1. 웹에 접근, 프론트로 로그인요청, 백으로 로그인api 요청, 유효성 및 존재여부 검증 2. mysql db에서 선택된 값 반환, 검증, 실패시..

채팅기능의 목적은 사용자와 운영자간의 소통인데, 두 가지 방식이 떠올랐다. 메신저처럼 실시간으로 통신하여 바로바로 메세지를 주고받을 수 있는 방식이 있겠고, 메일을 주고받듯 페이지가 리로드되면 받을 수 있는 방식이 있을 것 같다. 이 두 차이는 페이지를 새로고침을 해야만 새 메세지를 확인할 수 있을 것인지, 혹은 새로고침을 하지 않아도 새 메세지를 확인할 수 있도록 할 것인지에 대한 차이라고 보인다. 아직 사용해보지는 않았으나 socket.io를 이용하여 대화방을 만든다던지, 특정 사용자에게 귓속말을 한다던지 하는 여러 기능들이 있다고 하는데, 당장 내가 적용할 프로젝트에서는 '실시간'이라는 키워드가 메리트로 다가오지는 않았다. 소켓io에 대해 조금 공부해보니, 별도의 서버를 추가로 운영하는 것이 서비스..