[Feature] FCM Enum Message 생성 및 테스트 API 구현 #130
Conversation
| @@ -66,6 +66,7 @@ dependencies { | |||
| // firebase | |||
| implementation 'com.google.firebase:firebase-admin:6.8.1' | |||
| implementation group: 'com.squareup.okhttp3', name: 'okhttp', version: '4.2.2' | |||
| implementation 'com.squareup.okio:okio:2.7.0' | |||
There was a problem hiding this comment.
'com.squareup.okhttp3' 를 사용하면서 'com.squareup.okio:okio'의 특정 버전을 명시적으로 지정하지 않았을 때 발생하는 오류인 것 같습니다. okhttp 라이브러리는 내부적으로 okio 라이브러리를 사용하기 때문에, okhttp의 특정 버전이 요구하는 okio의 버전이 자동으로 끌어져 오는데 이 과정에서 문제가 발생했던 것 같아요!
의존성을 추가함으로써, okio이 명시적인 버전을 지정했고 이게 호환성 문제를 해결한 것으로 보입니다! okhttp 4.2.2와 okio 2.7.0은 서로 호환되는 버전이라고 합니다!
There was a problem hiding this comment.
자세하게 찾아보고 리뷰 남겨 주셔서 감사합니다!
의존성을 추가하고 사용하는 데 충돌 문제도 종종 있는 거 같아요!
firebase 최신 버전에 대한 의존성을 추가하고 로직을 깔끔하게 변경하려고 했었지만, log 라이브러리와의 충돌이 나서 롤백했는데 이 부분 슬랙에 조금 더 적어두었습니다!
There was a problem hiding this comment.
슬랙 확인했는데 내일 좀 더 꼼꼼히 살펴보고 올테니 다시 이야기 해봐요~!
레퍼런스가 부족하다면, 직접 만드셔도 좋을 듯 합니다 😉
| }) | ||
| @PostMapping("/fcm-test") | ||
| public ResponseEntity<Void> testFcmToken(@Valid @RequestBody FcmTokenRequest request) { | ||
| fcmService.sendMessageTo(request.fcmToken(), APPLICATION.getTitleWithLoc("서울 강남구", "서울 도봉구"), APPLICATION.getBodyWithName("포윗유")); |
There was a problem hiding this comment.
우와 enum 활용 완전 유용하네요! 이렇게 해서 enum 타입과 enum 클래스에 선언한 메소드를 활용할 수 있군요👍
There was a problem hiding this comment.
알림 메시지를 어떻게 설정할까 고민하다가 동일한 형태라면 enum으로 관리하는 게 좋을 것 같다고 생각하고 구현했는데 다행이네요~!
| } | ||
|
|
||
| public String getBodyWithName(String name) { | ||
| return name + body; |
There was a problem hiding this comment.
enum 타입에 체이닝으로 메소드 호출할 수 있는 걸 활용한 좋은 예시 같아요!
There was a problem hiding this comment.
FCM 토큰을 별도의 테이블에 저장하는 경우
장점
- 사용자가 여러 기기를 사용할 경우 각 기기별로 다른 토큰을 저장할 수 있음
- 토큰과 관련된 추가 정보(기기 유형, 등록 날짜 등)를 저장할 필요가 있을 때 쉽게 확장 가능
- 데이터베이스 정규화 원칙에 따라 중복을 최소화하고 데이터 무결성을 유지함
단점
- 사용자 정보와 토큰 정보 조회할 때 조인 작업 필요
- 별도 테이블 관리
FCM 토큰을 사용자 테이블의 컬럼으로 포함하는 경우
장점
- 사용자 정보와 토큰이 동일한 테이블에 있어 단일 조회로 모든 정보 조회 가능
단점
- 각 사용자가 여러 기기를 사용할 경우, 토큰 관리가 복잡해질 수 있음
- 중복 데이터가 발생할 수 있으며, 데이터 무결성 유지가 어려워질 수 있음
|
결론 사용자당 여러 기기를 사용하는 경우가 많다면 별도의 테이블을 유지하는 게 좋음 현재 방식대로 가는 게 공수가 많이 들지 않으면 이대로 가고, 그게 아니라면 변경하면 될 것 같습니다! 현재 방식대로 가도 될 것 같은데 어떤가요~? |
|
사용자가 여러 기기를 사용할 경우 별도 테이블을 유지하는 게 좋다고 생각합니다! |
|
우리의 설계에선 조인이 필요하지 않고, 확장성, 정규화 부분까지 고려하면 지금 방식으로 가면 좋을 것 같은데! 저도 더 알아보고 오겠습니다. |
💡 연관된 이슈
close #129
📝 작업 내용
💬 리뷰 요구 사항
상황별로 알림 메시지를 보여주기 위해 NotificationMessage를 Enum 타입으로 만들었습니다!
ErrorCode와 같은 형식이라고 생각하면 이해하기 쉬울 것 같습니다!
또한 테스트 코드를 실행하는 데 있어 의존성 문제가 발견되었습니다. (실행에는 문제 없음)
build.gradle에 해당 의존성 관련 설정은 없었지만, 에러가 발생할 가능성을 대비해 의존성 버전을 업데이트해 해결했습니다.
그리고 저희가 현재 이동봉사자와 이동봉사 중개 테이블이 나뉘어서 FCM token도 따로 각각 테이블을 만들어서 저장해뒀는데, 컬럼에 FCM token을 넣는 것과 현재 방식 중에 어떤 방식이 더 좋을지 고민입니다!
컬럼에 저장하는 건 정규화에 맞지 않는 설계인 거 같다고 생각해 테이블을 분리했는데 고민입니다!