Ting (임시 보류)

로고 초안!

 

 

 

 

형상관리

 

{tag}: [{place}] 내용

feat: 기능 추가
modify: 버그 아닌 코드 수정
fix: 버그 수정
refactor: 코드 리팩토링
style: 코드 스타일(코드 컨벤션 추가) 수정
docs: 문서 작업
design: 프론트 CSS 수정
test: 테스트 코드 작성
chore: 프로젝트 설정 파일 수정
create: 프로젝트 생성
rename: 파일이나 폴더명을 수정하거나 옮기는 작업만 수행
remove: 파일을 삭제하는 작업만 수행

 

 

프런트

CRA > yarn4 + vite 

빌드속도 - 476 > 75 초

 

 

 

FSD 의 장점과 프로젝트의 성향에 맞게 수정

 

FSD란?

https://feature-sliced.design/kr/docs/get-started/overview

둘러보기 | Feature-Sliced Design

 

 

 

 

 

 

백

선정하기

 

 

디자인 패턴 Tree 구조 형성하기 

옵션1. 컨트롤러끼리 모으기:
장점:
특정 역할과 기능이 분명히 구분됨.
같은 종류의 파일들이 한 곳에 모여 있어서 찾기 쉬움.
단점:
기능별로 나누지 않아 컨트롤러 파일의 개수가 많아질 경우 탐색이 어려움.
특정 기능 관련 파일을 찾기 위해 여기저기 찾아봐야 할 수 있음.

 

옵션2.  기능 단위로 컨트롤러와 서비스를 구분:
장점:
특정 기능(서비스) 관련 코드들이 한 폴더에 모여 있어 전체 구조를 이해하기 쉬움.
특정 기능을 유지보수하거나 수정할 때 효율적임.
단점:
기능 간의 공통 로직이 중복될 가능성이 있음.
전체 컨트롤러를 한눈에 보기 힘들 수 있음.
보편적으로는 기능 단위로 컨트롤러와 서비스를 나누는 방식이 유지보수성과 확장성 측면에서 더 많이 사용됩니다. 하지만 팀의 필요와 프로젝트의 규모에 맞추어 유연하게 선택하는 것이 중요합니다.

 

나는 2번을 선택하였다.  그 근거로는 

1. 프런트 리듀서와 구조를 맞추기 위해서 
2. 기능단위 배포를 위해서

3. 모듈화 및 책임 분리 

4. 확장성

5. 인원 추가로 인한 협업을 고려 

 

 

 

 

 

디비 와의 연결

선택지

 

 

 

 

 

 

 

GraphQl 도입 안한 이유

https://yozm.wishket.com/magazine/detail/2113/

개발자에게 편리함을 주는 ‘GraphQL’ 도입 시 주의할 점은? | 요즘IT

 

 

 

 

 

프리즈마 장점

 

 

프리즈마 단점

https://velog.io/@dkvlg/%EB%B2%88%EC%97%AD-%ED%94%84%EB%A6%AC%EC%A6%88%EB%A7%88-%EC%93%B0%EC%A7%80-%EB%A7%88%EC%84%B8%EC%9A%94

[번역] 프리즈마 쓰지 마세요

 

 

테스트 

 

 

 

 

결론 : 프리즈마 를 사용하자

- 속도가 빠르다. 

- 개발 속도가 빠르다 .

- 스웨거 사용에 문제가 없다 .

 

추가사항

-수정 사항 있을시 디비를 직접 바꾸자 (프리즈마에서 바꾸고 push 시 데이터 삭제의 위험이 있다)

-디비 컬럼 형식을 바꾸자

before: prefix 컬럼명에 포함 (쿼리 작성시 혼동 방지용- 여러 테이블 join 시)

after: prefix 컬럼명에 제거 (user.userid > user.id 로 사용 가능)

 

 

로직

사용자 로그인에 관하여 

 

 

세션 jwt 

 

 

 

보안 에 관하여 

 

 

 

 

추가 이슈 사항 

쿠키에 저장하면 모바일 환경에서 문제가 생길 수 있다 

 

 

결론부터 말씀드리면 Refresh Token은 HttpOnly 쿠키로 저장합니다.
accessToken 은 메모리에 >> 리덕스에 


accessToken 막는건 블랙리스트로 >> stateless 가 별로 > 리프레시를 블랙리스트? >> 보단 그냥 삭제 

 

 

리프레시 토큰
삭제로 무효화 가능: 데이터베이스에서 리프레시 토큰을 삭제하면 신규 액세스 토큰 발급을 막을 수 있으므로 무효화가 적절히 이루어집니다.
액세스 토큰
토큰 블랙리스트 필요: 액세스 토큰은 자체적으로 유효 기간이 있으며, 서버 측에서 상태를 저장하지 않기 때문에 서버에서 해당 토큰이 유효한지를 확인할 수 없습니다. 따라서 액세스 토큰의 수명이 남아있다면 외부 호출에서 무효화하기 어렵습니다.
블랙리스트 구현: 특정 토큰을 무효화하고 싶다면 블랙리스트를 구현해 기존 액세스 토큰이 더 이상 허용되지 않도록 할 수 있습니다. 이 방법은 완전한 무상태성을 보장하지 않지만 필요 시 사용할 수 있습니다.


즉각적 대응 필요 시: 사용자의 액세스 토큰 사용을 즉시 막아야 하는 경우 액세스 토큰 블랙리스트를 사용합니다.
장기적 차단: 특정 사용자의 세션을 완전히 종료하고 재인증을 요구하고자 한다면, 리프레시 토큰 블랙리스트에 추가하는 것이 좋습니다.

무상태성을 유지하는 것이 좋은지 여부는 애플리케이션의 요구사항과 아키텍처에 따라 다릅니다. 하지만 일반적으로 다음과 같은 장단점을 고려할 수 있습니다.

장점
확장성:
서버가 클라이언트의 상태를 저장하지 않기 때문에 수평 확장이 용이합니다. 서버 간의 상태 동기화가 필요하지 않아서 부하 분산이 쉬워집니다.
단순성:
서버 로직이 복잡해지지 않으며, 요청 자체만으로 필요한 모든 정보가 제공되기 때문에 구현이 단순해집니다.
복원력:
서버에서 상태를 관리하지 않기 때문에, 서버 중단 시에도 클라이언트의 상태에 영향을 주지 않습니다. 어떤 서버로도 요청을 처리할 수 있습니다.
단점
보안 문제:
모든 요청이 토큰과 같은 인증 정보를 포함해야 함으로써, 이를 안전하게 관리하는 것이 중요합니다.
토큰 무효화의 어려움:
액세스 토큰을 즉시 무효화할 수 있는 효율적인 방법이 부족합니다. 이를 해결하기 위해 블랙리스트나 상태 저장 방식이 동원될 수 있습니다.
데이터 전송량 증가:
모든 요청에 인증 정보를 포함하므로, 네트워크 오버헤드가 증가할 수 있습니다.

 

 

로그인
https://velog.io/@hyojhand/Refresh-Token-%EB%B8%94%EB%9E%99-%EB%A6%AC%EC%8A%A4%ED%8A%B8-%EB%8F%84%EC%9E%85%EA%B8%B0

https://engineerinsight.tistory.com/232#google_vignette

https://velog.io/@snghyun331/Nest.js-Refresh-Token%EC%9C%BC%EB%A1%9C-%EB%A1%9C%EA%B7%B8%EC%9D%B8%EB%A1%9C%EA%B7%B8%EC%95%84%EC%9B%83-%EB%B3%B4%EC%95%88-%EA%B0%9C%EC%84%A0


//스케줄링
https://velog.io/@from_numpy/NestJS-%EB%B3%B4%EC%99%84-refresh-token-%EB%A7%8C%EB%A3%8C%EC%8B%9C-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%88%98%EC%A0%95-feat.-task-scheduling-setTimeout


https://velog.io/@bnb8419/Axios-Interceptor%EB%A5%BC-%ED%86%B5%ED%95%B4-Refresh-Token%EC%9C%BC%EB%A1%9C-Access-Token-%EC%9E%AC%EB%B0%9C%EA%B8%89%ED%95%98%EA%B8%B0


https://velog.io/@ehdrms2034/Access-Token-%EC%A0%80%EC%9E%A5-%EC%9C%84%EC%B9%98%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B3%A0%EC%B0%B0



https://gusrb3164.github.io/web/2022/08/07/refresh-with-axios-for-client/


https://velog.io/@iamtaehoon/sagah
https://velog.io/@yaytomato/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%90%EC%84%9C-%EC%95%88%EC%A0%84%ED%95%98%EA%B2%8C-%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%B2%98%EB%A6%AC%ED%95%98%EA%B8%B0
https://velog.io/@ohzzi/Access-Token%EA%B3%BC-Refresh-Token%EC%9D%84-%EC%96%B4%EB%94%94%EC%97%90-%EC%A0%80%EC%9E%A5%ED%95%B4%EC%95%BC-%ED%95%A0%EA%B9%8C


https://sponge-palm-382.notion.site/381cbb45c07f4de9b7f720ace18d33be


https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-11


https://velog.io/@wjdghks963/Prisma%EC%9D%98-%EB%8B%A8%EC%A0%90-%ED%83%90%EA%B5%AC






https://velog.io/@yaytomato/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%90%EC%84%9C-%EC%95%88%EC%A0%84%ED%95%98%EA%B2%8C-%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%B2%98%EB%A6%AC%ED%95%98%EA%B8%B0


https://blog.naver.com/pjt3591oo/222689578991


인메모리 기능 빠른 토큰 처리
https://mariadb.com/kb/en/memory-storage-engine/



https://hshine1226.medium.com/localstorage-vs-cookies-jwt-%ED%86%A0%ED%81%B0%EC%9D%84-%EC%95%88%EC%A0%84%ED%95%98%EA%B2%8C-%EC%A0%80%EC%9E%A5%ED%95%98%EA%B8%B0-%EC%9C%84%ED%95%B4-%EC%95%8C%EC%95%84%EC%95%BC%ED%95%A0-%EB%AA%A8%EB%93%A0%EA%B2%83-4fb7fb41327c