Service에서 다른 Service 의존 vs 다른 Repository(Dao) 의존
•
비즈니스 제약사항의 사용이 필요하다면 (일반적으로 CUD)Service, 그렇지 않다면 Repository (일반적으로 Read)!
•
파사드 패턴
◦
어디쪽인지 모호한 친구들 → 묶어서 더 상위 레이어 만든다.
•
레퍼런스
•
추가 궁금증) 컨트롤러에서 여러 서비스들 의존하는 구조는 왜 나쁜가? 트랜잭션 전파가 안일어나나? 기존 police 레거시 구조가 이렇게 되어 있는데 바꿀 합당한 이유 찾기!
CICD
•
오랜만의 cicd 구축! 이번이 6,7번째 cicd 구축이었는데 예전과 달리 정말 수월하게 구축할 수 있었다.
•
에러 요인 : 보안 그룹 8080 안열어뒀었고, docker build할 때 경로를 dockerfile이 있는 곳에서 하지 않았음. private key로 openSSH 주는 거 까먹고 ppk 넣음.
•
2트만에 성공!
AccessToken 재발급 로직
•
먼저 깃허브를 탐방해 다른 프로젝트 코드들을 보면서 로직을 정리해보자.
◦
1번) 두둥 : Token Entity: refreshToken, user / token: id
▪
refreshToken으로 db에서 Token Entity 찾기
▪
Token Entity의 refreshToken을 파싱해서 id 찾기
▪
id로 db에서 User Entity 찾기
▪
User Entity의 oauthInfo로 재로그인 시키기
▪
User Entity로 accessToken 재생성하기
◦
2번) 아띠즈(내 플젝) : Token Entity: refreshToken, user / token: loginId, role
▪
refreshToken으로 db에서 Token Entity 찾기
▪
Token Entity의 refreshToken을 파싱해서 expiration 찾기
▪
만료 시간이 지니지 않았으면 refreshToken 속 내용으로 accessToken 재생성하기
▪
만료 시간이 지났으면 TOKEN_EXPIRED 에러 내보내기
◦
3번) 비치컴바인 (내 플젝) : Token Entity: refreshToken, user / token: loginId
▪
refreshToken 유효한지 확인
▪
refreshToken 파싱해서 loginId 찾기
▪
loginId와 refreshToken으로 db에서 Token Entity 찾기
▪
loginId로 db에서 Member Entity 찾기
◦
4번) 아이러빗(회사 다른 플젝) : Token Entity: refreshToken, accessToken, user / token: id