배꼽파지 않도록 잘 개발해요

https://docs.uaparser.dev/intro/quick-start/using-es-modules-typescript.html 만약 named export를 default export처럼 import 하면 다음과 같은 일이 발생한다.This expression is not constructable. Type 'typeof UAParser' has no construct signatures.ts(2351)(alias) namespace UAParser import UAParser "This expression is not constructable": new UAParser()로 인스턴스를 만들 수 없다 "Type 'typeof UAParser' has no construct signatures"..

Stateful (상태 유지 시스템)- 상태(state)를 시스템이 기억하고, 사용자가 이전에 했던 작업이나 데이터를 다음 요청에서도 계속 유지- 예를 들어, 사용자가 로그인하면 세션을 통해 로그인 상태가 유지되며, 이후 요청에서도 로그인 상태가 계속 유지됨. 상태가 유지되기 때문에, 이전 작업의 결과나 데이터를 바탕으로 추가 작업을 진행할 수 있음.- 장점 : 사용자의 이전 데이터를 기억하여, 연속적인 작업을 할 수 있음.- 단점 : 상태를 관리하기 위한 서버 자원과 비용이 필요하고, 여러 서버 간에 상태를 일관되게 유지해야하므로 복잡할 수 있음.- 예시 : 데이터베이스의 세션 정보는 stateful한 방식. 사용자가 세션을 종료하거나 시간이 지나면 그 상태가 사라짐. Stateless (상태 비유지 ..

1. 세션 vs jwt : 세션 기반 인증은 요청마다 세션을 조회해야하므로 시간이 더 걸리지만, jwt는 별도의 세션 조회 없이 유효성만 확인하면 되어 속도가 더 빠름. 2. 백엔드와 데이터베이스가 같은 데이터센터에 있는지 확인 : 백엔드와 데이터베이스가 같은 AWS 리전 내에 있으면 물리적 거리가 짧아져 통신 속도가 빨라짐. 3. VPN 사용 : 같은 데이터센터 내에서는 VPN을 통해 통신하면 더욱 빠른 속도가 가능함. 4. 서버와 클라이언트의 거리 : 서버가 클라이언트와 물리적으로 가까운 곳에 있을 수록 응답 시간이 짧아짐. 예를 들어, 서울에 서버가 있고 클라이언트가 한국에 있으면 더 빠르고, 미국이나 유럽에 있으면 더 느려짐. 5. 글로벌 서비스의 경우 : 전 세계에서 빠르게 서비스를 하려면 백엔..

현재 마무리하고 있는 프로젝트에서는 NestJS, express-session, connect-redis, passport를 사용하여 인증을 처리하고 있다.express-session은 세션을 생성하고 관리하며, passport는 인증을 처리하고 인증 정보를 세션에 저장한다.express-session에서 세션을 생성할 때 발급해주는 쿠키는 기본적으로 이름이 'connect.sid'이다. 프론트엔드에서 세션 상태를 확인하는 API를 만들어달라고 해서 작성하던 도중,request의 cookies에서 세션 ID를 추출해야겠다고 생각하였다. 원래 쿠키에서 세션 ID 추출하는 함수는 이런식으로 사용하고 있었다. 이게 connect.sid 쿠키의 값이라고 하면s%3AtWwtNorRjA3u5-SVHMecRQblBv..

벌써 프로젝트가 1차적으로 마무리되었다. 우리 서버는 NestJS 프레임워크를 사용하여 express-session과 connect-redis, passport를 통해 세션 인증을 사용하고 있다. 이전 프로젝트에서 토큰만 사용해봐서 쿠키와 세션을 사용하는 것이 굉장히 낯설었다. 프로젝트 시행착오의 70%는 인증 쪽이고, 30% TypeORM 쪽이다. https://programming-bellybutton.tistory.com/215  [중간이들] NestJS 세션 로그아웃 구현 중 쿠키 문제 해결 과정NestJS 서버에서 express-session과 passport, connect-redis를 사용하여 세션 로그인을 구현하였다.API를 점검하는 도중에 로그아웃에 문제가 있는 것을 발견하였다.어제 몇 ..

NestJS를 사용하다보면 express에서 Request와 Response 객체를 직접 import 해야할 일이 있다. 예를 들면 Response 객체를 사용하여 클라이언트에 쿠키를 설정하거나 전송해야하는 일, 미들웨어 작성, 거의 없지만 파일 전송 등의 경우가 있다. 컨트롤러에서 만든 API를 Thunder Client로 테스트하던 도중 응답이 pending 상태가 되는 일이 발생하였다. 이럴 경우 무조건 내가 코드를 잘못 쓴 것이기 때문에 컨트롤러부터 살펴봐야한다.auth.controller.ts 파일을 살펴보니 해당 API에서 @Res() 데코레이터를 주입하여 사용하고 있었다. 코드를 아래처럼 수정하면 잘 작동한다. @Res 데코레이터를 삭제하거나, 아니면 @Res 데코레이터를 사용하면서 resp..

현재 프로젝트의 NestJS 서버에서는 Redis를 사용하고 있다.다른 백엔드 개발자분의 브랜치를 dev에 merge를 하고, 그걸 현재 내가 작업하는 브랜치에 merge를 하였다.Conflict가 나서 코드는 해결하였으나, 실행할 때 다음과 같은 오류가 났다. 로컬에서 6379 포트로 Redis가 접속이 되지 않는다는 오류가 떴다.그런데 나는 분명히 로컬에서 Redis를 연결하여 사용한 적이 없다. Redis Cloud에서 받은 Host, Port, Password를 입력하여 Redis Module을 만들어 사용하였기 때문이다. 가장 최근에 변경된 posts.service.ts 코드를 확인해보니 Redis Client를 생성할 때 어떠한 인자도 넣지 않고 있었다.this.redis = new Redis..

이번 프로젝트에서 Redis를 사용할 일이 많아졌다. 회원가입 후 이메일에 발급하는 토큰회원의 세션 정보좋아요 수 업데이트 등 Redis에 데이터를 입출력할 일이 많아졌다. 그래서 데이터를 직접 확인해야할 일이 생겼다. Redis를 활용할 때는 Redis Cloud와 Redis insignt를 사용하면 된다.  Redis Cloud : 클라우드 기반의 서비스, 데이터베이스와 관련된 정보만 확인 가능. 세부적인 데이터 내용은 직접 확인할 수 없고 관리도 불가능함.Redis Insight : Redis의 GUI 도구, 실제 데이터베이스 내의 데이터를 직접 확인할 수 있으며, CLI 명령어를 사용하여 데이터를 관리할 수 있음.Redis Cloud 사용은 아래 블로그의 글을 참고하였다.https://inpa.t..

상황 설명 우리 팀의 브랜치 - dev : 우리 팀의 default 브랜치, 모든 작업은 여기다 합침 - feature/user : 내가 작업하려고 새로 만든 브랜치 - feature/post : 다른 분이 작업하신 브랜치 상황 - 내가 feature/user을 새로 만들어서 작업하고 커밋을 했음. - 그런데 feature/post 작업 결과가 dev에 반영이 안 된 상태임. - 그래서 dev 브랜치에 feature/post를 merge를 하였음. - 나는 dev브랜치의 최신 내용을 현재 있는 브랜치(feature/user)에 반드시 가져와야만 함. 이럴 때는 어떻게 해야할까? 1. Merge를 한다.현재 브랜치에 dev브랜치의 변경사항을 합친다.# 현재 브랜치에서 작업하고 있는지 확인git status..

프로젝트 리팩토링을 아직도 하고 있는데, 검색 API를 만들다가 쿼리를 제대로 사용하지 못하여 시간을 엄청 허비하는 일이 있었다.결론부터 말하면 1번 코드로 작동해서 안 되다가 2번 코드로 수정하니 잘 해결되었다.이게 왜 안 되는지 파악하는데 꽤 많은 시간이 걸렸다.  상황 : feed 모델 안에 travelPlan 모델을 populate한 상태임.1번결과 : 모든 글이 다 조회됨. // 제목 // travelPlan의 title if (title) { const feeds = await this.feedModel .find() .populate({ path: 'travelPlan', match: { title: title..