일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- Python
- MySQL
- flask
- mongoose
- Nest.js
- AWS
- Queue
- Express
- Bull
- game
- typeORM
- 정렬
- jest
- dfs
- GIT
- MongoDB
- JavaScript
- 공룡게임
- Dinosaur
- 게임
- class
- nestjs
- cookie
- react
- 자료구조
- nodejs
- OCR
- Sequelize
- TypeScript
- Today
- Total
목록Redis (5)
포시코딩
개요 https://4sii.tistory.com/422 https://4sii.tistory.com/423 https://4sii.tistory.com/428 https://4sii.tistory.com/456 이전에 작성됐던 동시성 문제 관련 글들은 적용하며 겪은 시행착오에 대한 내용이라면 이번 글은 성공적으로 완성된 모임 참여 로직에 대한 전체적인 설명이 내용이 되겠다. 흐름을 돕기 위해 코드 중간중간 console.log()로 설명을 추가했다. 들어가기 앞서 이제부터 코드를 볼건데 코드만 보면 이해하기 어렵기 때문에 이해를 돕기 위해 그림으로도 그려봤다. 보다가 흐름이 이해가 가지 않는다면 위로 올라와 어떤 메서드에서 어떤 흐름으로 진행되고 있는지 한번 보고나서 코드를 보면 도움이 될 것이다. 클..
개요 https://4sii.tistory.com/423 [Nest.js][동시성 문제] Bull Queue - 작성중 개요 https://4sii.tistory.com/422 [동시성 문제] (1) Transaction 사용과 통 Lock 걸어버리기 코드 Back-End: Nest.js - boards.service.ts async joinGroup(boardId: number, userId: number) { const board = await this.getBoard(boardId); const boar 4sii.tistory.com 위 글에서 이어진다. 프로젝트 시작 전 최대한 생길 수 있는 문제에 대해 기술적인 해답을 얻고 들어가기로 했으나 내가 담당했던 동시성 문제는 끝내 완벽하게 해결하지 못..
개요 https://4sii.tistory.com/437 [Nest.js] 이메일 인증 시스템 (2). cache-manager 개요 https://4sii.tistory.com/436 [Nest.js] 이메일 인증 시스템 (1). nodemailer 개요 위와 같은 회원가입 폼에서 이메일 입력 후 인증번호 전송을 누르면 해당 이메일로 랜덤한 6자리 숫자의 인증번호가 보 4sii.tistory.com 이전 글에서 cache-manager를 통해 이메일과 인증번호를 캐싱한 후 사용자가 이메일로 전달받은 인증번호를 입력 시 확인하는 로직을 만들어봤는데 이번에는 이 과정에서 사용된 cache-manager를 redis를 이용하게 바꿔 볼 예정이다. 문제 발생 https://docs.nestjs.com/tech..
개요 https://4sii.tistory.com/422 [동시성 문제] (1) Transaction 사용과 통 Lock 걸어버리기 코드 Back-End: Nest.js - boards.service.ts async joinGroup(boardId: number, userId: number) { const board = await this.getBoard(boardId); const boardJoinInfo = await this.joinRepository.find({ where: { boardId }, }); if (board.joinLimit { if (join.userId 4sii.tistory.com 이전 포스팅에서 이어진다. 이전에 고민했던 동시성 문제에 대해 Queue 디자인 패턴을 활용해 해..
개요 처음으로 토큰 기반 로그인 인증을 구현하며 access token과 refresh token을 다루게 되었는데 refresh token을 저장하는 방법으로 그냥 다른 데이터들 처럼 MySQL에 Token 테이블을 만들어 저장했었다. 그랬더니 이미 사용된 후의 token 데이터들이 계속 쌓이고 짧은 access token 만료시간으로 인해 middleware 통과할때마다 refresh token으로 위 데이터를 조회하고 있었다. 사실 refresh token은 redis에 저장하는게 제일 좋다고 배워서 그렇게 하고 싶었으나 하루동안의 삽질 뒤에 포기하고 MySQL로 도망간거였음 이번에 시간이 되서 제대로 다시 해보고 난 다음 정리하게 되었다. 왜 redis? 최근에 MongoDB 다루는 법도 배웠었고..