✨ Device Token 등록/수정/삭제 API

[psychology50]

작업 이유

• 사용자의 Device 정보와 Device Token 저장 API 구현
• 사용자의 Device 정보를 제거 API 구현

작업 사항

📝 Device 정보 등록 플로우

{
    "originToken": "",
    "newToken": "",
    "model": "",
    "os": ""
}

1. Client에 캐싱된 token이 없는 경우
   • originToken == newToken 요청을 보낸다.
   • 서버는 요청자의 Device로 해당 device 정보를 갱신한다.
2. Client에 캐싱된 token이 존재하여 수정을 요청하는 경우
   • 서버는 userId에 매핑된 originToken 정보를 탐색한다. (없으면 NOT FOUND)
   • Device 정보를 찾았으나, 모델 정보가 다른 경우 업데이트
   • Device Token을 newToken으로 갱신
   • Device Token이 비활성화 상태라면 활성화 상태로 전환

❓ 예상 질문 답변 모음

1. Device Token이 unique 필드가 아닌 이유
   • 여러 사람이 하나의 기기로 로그인 했을 경우, 서로 다른 User에게 같은 device token 정보가 등록될 수 있기 때문입니다.
2. 기기 정보가 바뀌었을 때, NOT_MATCH 에러가 아니라 정보를 수정하는 이유
   • 모델명이 바뀔 일은 잘 모르겠지만, OS는 분명히 달라질 수 있기 때문입니다.
3. 토큰을 삭제하지 않고, 활성화/비활성화 컬럼을 추가한 이유
   • 현재 저희 정책은 Client 측에서도 토큰 유효성 검사를 수행하면서, 추후 Server에서도 토큰 관리를 위한 스케줄러를 구현하게 됩니다.
   • 만약 Client가 Device Token을 발급받아 서버에 저장한 후, 한 달 정도 앱을 실행하지 않은 경우 서버의 스케줄러가 해당 토큰을 비활성화 했을 확률이 높습니다.
   • 이 경우 Client는 수정 요청을 보냈으나, Server는 originToken을 식별하지 못 해 요청에 실패하게 됩니다.
   • 따라서 만료된 토큰은 비활성화 처리하여, Client의 수정 요청에 대응하도록 합니다.
4. 토큰 저장 요청(originToken == newToken, 예상 질문 4번) 시, 토큰 존재 여부를 먼저 검사하는 이유
   • Server에는 활성/비활성 토큰이 존재하지만, 사용자가 app의 데이터를 제거해버린 경우 발생합니다.
   • 사용자가 앱 데이터를 삭제하고 실행할 때마다 활성화 토큰이 계속해서 저장될 가능성이 있어, 이미 존재하는 경우 model, os 버전만 변경 사항을 반영합니다.

🟢 테스트 케이스

1️⃣ Controller Unit Test

2️⃣ Service Unit Test

🤔 test에 fixture, supporter...양재서 너 이 자식, 또 PR 관심사 분리 실패냐?

📢 진정하고 제 이야기를 들어보십시오.

🚨 문제 상황 발생

• Controller Unit Test 시, isAuthenticated() 인가 조건에 의해 @WithMockUser를 사용했으나 에러 발생

• @AuthenticationPrincipal 어노테이션이 SecurityUserDetails를 알지 못 하기 때문에 생기는 이슈

💡 해결 방법

@Retention(RetentionPolicy.RUNTIME)
@WithSecurityContext(factory = WithCustomMockUserSecurityContextFactory.class)
public @interface WithSecurityMockUser {
    String userId() default "1";
}

• @WithMockUser 대신, 제가 만든 커스텀 어노테이션 @WithSecurityMockUser를 사용하면 됩니다.
• @WithMockUser에 userId를 값을 지정하지 않으면, 언제나 userId는 1입니다.
• 통합 테스트 환경에선 애초에 MockUser를 사용할 이유가 없으므로, 인가 권한이 isAuthenticate()인 Controller Unit Test에만 사용하면 됩니다.
• 해당 블로그에 잘 정리되어 있습니다.

🔪 Fixture는 뭔데?

• 반쯤 재미삼아 사용해봤습니다...이 블로그를 참고하시면 돼요.
• 다만, 디렉토리 경로를 매우 무신경하게 정했기 때문에 재조정이 필요합니다. (애초에 테스트 Convention이 너무 없는 상태)
• 뭔가 편한데 생각보다 사용이 까다로워서, 일단 이번 테스트에만 적용해보고 반응을 보고 싶었습니다.

리뷰어가 중점적으로 확인해야 하는 부분

1. 비지니스 로직을 담당하는 DeviceRegisterService이 설계 원칙을 준수하고 있다고 보는지? (이름, 내부 메서드 등)
2. 시나리오에 문제점이 있거나, 잘못된 테스트 케이스가 있는지?
3. 발견한 이슈 (2)번 꼭 확인해주세요!!

발견한 이슈

1. 현재 서버가 스케줄링을 통해 비활성화 한 토큰을 Client 측에서 제거해버린 경우에 대응하지 못 함. (쓰레기 데이터 누적)
   • 관리 정책을 수립하여 제거할 지, 로직을 수정할 지 모르겠음..
2. 현재 토큰이 바뀌지 않았음에도 Device 정보가 수정되면 updated_at 필드가 수정되는 현상이 발생합니다. 이로 인해 FCM 관리 정책이 무의미해질 수 있습니다.
   • 해당 시나리오는 사용자가 app 데이터를 제거하고 디바이스 업데이트 후, 앱을 다시 실행했을 때 발생 가능합니다. (Server에는 여전히 유효한 token이 존재하므로)
   • Table을 분리할 지, 제 설계 상 문제가 있는지 고민해봐야 할 문제입니다.

[jinlee1703]

이번 PR은 작업량이 많네요.. 고생하셨습니다!!

• PR 내용대로 디바이스 토큰 관리 정책에 대해 한번 더 이야기해봐도 좋을 것 같습니다.
• 저도 이야기했던대로 Mapper보다는 상위 서비스 개념으로 xxxService(ex: DeviceRegisterService)로 명명하는 것이 보다 직관적이라고 생각합니다!
• 디바이스 토큰 관리 로직의 경우에는 현재 전체적인 구조가 헷갈려서, 제가 문서를 보고 따로 생각을 정리해본 후 모르는 부분에 대해 질문하겠습니다.

[psychology50]

• PR 내용대로 디바이스 토큰 관리 정책에 대해 한번 더 이야기해봐도 좋을 것 같습니다.

해당 시나리오는 이슈로 추가 등록해두겠습니다!

• 저도 이야기했던대로 Mapper보다는 상위 서비스 개념으로 xxxService(ex: DeviceRegisterService)로 명명하는 것이 보다 직관적이라고 생각합니다!

앗, 이건 다소 오해가 있는 것 같습니다.
제가 이전에 Mapper를 사용했던 방식은 직관적이거나 하는 것과 무관하게 그냥 틀린 방식이라 여깁니다.

전 단순히 Mapper를 여러 DB에서 정보를 가져온 후 가공하는 중간 단계라 여기고 작업하다보니, Service를 써야 할 지 Mapper를 써야 할 지 혼동하고 있었던 건데,
이번에 작업하면서 느낀 것은 Mapper는 data에 관심을 가지고 있고, (application 모듈의)Service는 핵심 비지니스 로직을 담아야 한다고 생각합니다.

즉, Helper와 Mapper는 비지니스 로직을 위한 클래스가 아닌 것 같더라구요.
기존 코드는 모두 리팩토링할 예정입니다.

• 디바이스 토큰 관리 로직의 경우에는 현재 전체적인 구조가 헷갈려서, 제가 문서를 보고 따로 생각을 정리해본 후 모르는 부분에 대해 질문하겠습니다.

저도 정리해두려고 했는데 블록체인 수업 들으러 가느라 잊어먹었네요.
내일 정리해서 공유하겠습니다!