• 11/19 야간 피드백

  while (authRepository.existsByUuid(createdUuid) && tryCnt <3){
  		createdUuid = "normal-"+ UUID.randomUUID().toString();
  		tryCnt++;
  }
  
  if(tryCnt == 3){
  		throw new BaseException(BaseResponseStatus.ATTEMPT_LIMIT_EXCEEDED);
  }
  

  ‘3’ 이라는 숫자 대신에 상수 이용

  private final int TRY_CNT_LIMIT = 3;
  
  while (authRepository.existsByUuid(createdUuid) && tryCnt<TRY_CNT_LIMIT){
  		createdUuid = "normal-"+ UUID.randomUUID().toString();
  		tryCnt++;
  }
  
  if(tryCnt == TRY_CNT_LIMIT){
  		throw new BaseException(BaseResponseStatus.ATTEMPT_LIMIT_EXCEEDED);
  }
  

• while문 대신 for 이용 권장

• uuid 생성은 현재 직접 문자열을 덧붙이는 방식으로 처리 ← “normal-” / “social-” 이라는 식별자를 붙이는 형태

• 이에 대해 utils 폴더에 UuidGenerator 클래스를 생성하여 처리하도록

  import java.util.UUID;
  
  public class UuidGenerator {
  	private static final String NORMAL_PREFIX = "normal-";
  	private static final String SOCIAL_PREFIX = "social-";
  
  	public static String generateUuid(String prefix) {
  		return prefix + UUID.randomUUID().toString();
  	}
  
  	public static String generateNormalUuid() {
  		return generateUuid(NORMAL_PREFIX);
  	}
  
  	public static String generateSocialUuid() {
  		return generateUuid(SOCIAL_PREFIX);
  	}
  }
  

String createdUuid = UuidGenerator.generateNormalUuid();

• 영민pm 님 의논사항

  1. feed 등록 → kafka → 구독 서비스에서 알림 받고 정보 합침 → kafka → 알림 서비스 (event chaining)

  2. feed 등록 → kafka → 알림 서비스 → 받은 값의 작성자 uuid를 통해 feign client로 구독 서비스 접근

     • 이 경우 feign client 로 인한 서비스간의 강한 결합 발생,

     • feign client로 구독 서비스 접근 시 만약 에러 발생한다면 알림 도메인의 경우 kafka에서 넘어온 메세지 소비가 되어 보상 로직으로 받은 값에 대해 다시 feign client로 보내는 처리 필요

     • 보상 로직의 경우는 feign client냐 kafka 냐 따질 것이 아님 kafka에 대해서도 이벤트를 받아 mongoDB등을 접근할 때 오류의 발생 가능성은 있음 kafka 이용시에는 트랜잭션 처리나 보상 로직 처리가 굉장히 중요함

     • 1/2/3 이벤트 발생 후 kafka → 4/5 이벤트 발생 5번 처리 도중 에러 발생할 경우에 대해 처리 가능한 방법으로

       1. 4-3-2-1 순서로 차례대로 트랜잭션들을 rollback 처리
       2. 5번 이벤트에 대해 재실행

       → 1의 경우에는 주문의 경우, 2의 경우에는 회원가입의 경우에 적합

  • 회원가입 과정에 대하여 닉네임과 uuid를 user 서비스에 넘기는 것에 대해
    • 입력 폼에 대해 “ (아이디/비밀번호) -다음→ (닉네임) “ 처리가 가능하다면 feign client 사용도 피할 수 있지만, (아이디/비밀번호) 입력 후 바로 종료할 경우 회원가입 과정이 전부 이루어진 후 종료된 것이 아니기에 auth DB에서 제거 해야 됨
      • 회원가입 서비스 로직이 아니더라도 “ (아이디/비밀번호) -다음→ (닉네임) “ 과정이 통틀어 회원가입
    • 회원가입에 대해 db 저장을 먼저 진행 시킨 후 nickname과 uuid를 첫 로그인 시 전달 할 경우 로그인에 대한 처리 필요 (회원가입은 간단하게, 부가작업은 로그인 시!)
      • ex: authDB에 login_try_state 컬럼(boolean)을 추가하여 로그인 시 uuid / token들 / login_try_state값을 전달 후 front 에서 ‘false’일 경우에는 uuid를 전달하여 nickname 입력 창을 만들고 이를 바로 user 의 api를 통해 전달 ← feign client를 사용할 필요가 없어짐, auth에서 nickname값을 redis를 통해서 관리할 필요도 없어짐