일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- class
- game
- dfs
- Dinosaur
- nestjs
- mongoose
- 게임
- AWS
- Express
- Nest.js
- GIT
- Bull
- JavaScript
- react
- cookie
- jest
- 공룡게임
- MySQL
- MongoDB
- nodejs
- Python
- Queue
- 정렬
- typeORM
- TypeScript
- Sequelize
- flask
- 자료구조
- OCR
- Today
- Total
목록TIL (128)
포시코딩
개요 이틀전 끝난 프로젝트는 원래 그냥 JavaScript가 아닌 기능 개발 완료 후 TypeScript로 마이그레이션 하는게 목표였다. 하지만 결국 기능 개발도 다 완성하지 못한채 기간이 끝나게 됐고 그에 따라 TypeScript 적용은 해보지도 못했다. 앞으로 해당 프로젝트를 보수하게 된다면 계획했던 TypeScript로의 마이그레이션도 진행하게 될텐데 솔직히 하기로만 했었지 어떻게 할지는 생각을 못했다가 이번에 노마드코더에서 TypeScript 공부를 하며 관련 내용을 공부하게 되어 정리해본다. 상황 가정 (1) myPackage.js export function init(config) { return true; } export function exit(code) { return code + 1; ..
IoC (Inversion of Control) 제어 역전. 이라는 뜻 class AppController { appService; constructor() { this.appService = new AppService(); } } 기존에는 위와 같이 사용하고 싶은 객체가 있으면 생성부터 소멸까지 직접 관리해야 됐었다. 이렇게 직접 생성하면 의존하는 서비스가 변경될 때 개발자도 그에 맞춰 코드를 수정해줘야 하는 번거로움이 있었다. 하지만 IoC는 개발자가 사용하고 싶은 객체를 직접 생성하는 것이 아니라 객체의 생명주기 관리 자체를 외부에 위임한다. ex) Nest.js IoC 컨테이너 즉, 객체의 관리를 컨테이너에 맡겨서 제어권이 넘어갔기 때문에 IoC(제어 역전)이라고 하는 것이다. IoC는 모듈 간 ..
개요 이전부터 프론트엔드로부터 전달 받는 값들에 대해 프론트엔드에서 validation 처리가 진행됐다는 가정하에 (귀찮은것도 있고) 백엔드에서는 최소한으로만 진행을 해왔었다. 하게 되더라도 팀원들과 controller에서 체크를 할거냐 service에서 체크를 할거냐 라는 토론을 하기도 했었다. 결국 controller는 service가 잘 작동하도록 데이터를 전달하는 역할을 하는것이고 어떠한 로직을 수행한다는건 service에서 해야되기 때문에 service에서 하는걸로 결론이 났었지만 하지만 지속적으로 validation이 추가로 필요할 것 같다는 피드백을 받았었고 그 방법으로 여러가지 추천을 받아 이번 기회에 정리해보려고 한다. validation 방법들 express에서 validation 하는..
개요 로그인된 상황에서의 API 테스트를 해야하는데 API 테스트 툴로 Thunder Client를 쓰고 있지만 어떻게 로그인 한 상태로 인식시켜 요청을 보낼지 감이 안잡혀 테스트를 못하고 있는게 있었다. 근데 사실 간단했음 현재 로그인 처리는 로그인 후 accessToken과 refreshToken을 발급해 Client에 던져주고 Client 쪽에서 알아서 cookie를 세팅한 상태로 API 요청할 때 Server에서는 cookie-parser를 통해 넘어온 cookie안의 acccessToken과 refreshToken을 사용하는 방식이다. 문제 파악 일단 client쪽에서 JavaScript를 통해 cookie를 저장한 상태로 API 요청할 때 header에 cookie가 포함되어 보내지는건 확인이..
개요 이런 bootstrap 테이블을 만들었는데 각 row에 대해 마우스를 갖다 댈 때 하이라이트 효과를 주고 싶었다. 다행히 bootstrap에서 class에 table-active만 넣어주면 하이라이트 효과를 줄 수 있는 기능이 있어 마우스를 갖다대면 -> table-active class 추가 마우스가 벗어나면 -> table-active class 제거 위 기능만 구현시키면 해결될 것으로 보였다. 구현 프론트엔드 지식이 부족해서 구글링을 좀 해봤더니 https://stackoverflow.com/questions/74089433/want-to-add-class-when-hover-the-div-with-vanilla-javascript Want to add class when hover the d..
새 프로젝트 시작하고 이틀동안 기획하느라 TIL 쓸 거리도 안생기고 시간조차 없다가 이제야 쓴다. 새롭게 프로젝트를 시작하며 겪은 문제들에 대해 정리해보았다. multer 이미지 파일명 한글 깨짐 현상 예전에 multer 사용할 때 파일명이 깨지는 현상이 발생하여 파일명에 대해 file.originalname = Buffer.from(file.originalname, 'latin1').toString('utf8'); 이렇게 세팅해주는 과정을 거쳐 해결했었는데 비슷하게 문제를 겪어 이 방법을 알려줬던 다른팀의 한분이 새로운 해결 방법을 알려주셨다. 'Content-Type': 'multipart/form-data; charset=UTF-8' 서버로 이미지 저장 요청을 보낼 때 header에 위 내용을 실어..
개요 Enum, Generic은 자주 접하다보니 어느정도 익숙해졌는데 Utility Type이라는 새로운걸 접해서 정리해봄 Partial Partial(파셜)은 특정 타입에 속해있는 집합을 모두 선택적으로 만드는 타입으로 변환 interface Toppings { tomatoes: boolean, onion: boolean, lettuce: boolean, } const toppingsIWant: Partial = { onion: true, letttuce: undefined, // 다른 집합은 있어도 되고 없어도 되고 undefined로 명시해줘도 됨 } ex) 햄버거 주문 API에서 토핑을 유저가 선택적으로 주문할 수 있게 인터페이스를 만들 때 유용 Required Partial의 반대. 특정 타입에..
개요 통합 테스트 코드를 작성하면서 정리하면 좋을 내용들을 포스팅해봄 특정 함수들에 대한 함수 모킹 (jest.fn()) const redisClient = require('../../src/utils/redis.util'); beforeAll(async () => { // ...생략 redisClient.set = jest.fn(() => {}); redisClient.expire = jest.fn(() => {}); }); 회원가입 - 로그인에 대한 통합 테스트 과정중 로그인 시에 발생되는 redis에 refresh token 저장하는 함수가 실행되어 redis에 수많은 데이터가 쌓이는 것을 발견했다. 그 과정 때문인지 에러도 같이 발생하여 발견하게 되었는데 위와 같이 beforeAll - 실행되기 ..
개요 테스트 코드를 작성하면서 의문이 들었던 부분이나 헤맸던 부분을 정리해봄 return이 avoid type인 메소드 users.repo createUser = async (userInfo) => { await this.usersModel.create({ email: userInfo.email, password: userInfo.password, // ...생략 }); }; unit test code test('users.repository createUser Method success', async () => { mockUsersModel.create = jest.fn(() => { return 'test'; }); const userInfo = { email: 'test@gmail.com', pas..
개요 로그인 할 때 서버에서 res.cookie를 통해 저장하던 쿠키를 document.cookie로 프론트에서 저장하게끔 변경하고 난 뒤에 middleware 등 다른 여러 요청들에서도 server에서 직접 cookie를 설정하는 부분들이 있어 그 부분들을 수정하고 있었다. 그중 middleware에서 특이한 현상을 발견했다. access token이 만료되고 refresh token을 통해 access token을 재발급 -> 다시 메인 페이지로 return res.render('index', { redirect: req.path, message: 'access token 재발급', accessToken: newAccessToken, }); 보낸 뒤 새로운 access token을 다시 저장 후 요청..