-
Notifications
You must be signed in to change notification settings - Fork 1
푸시알림 권한 받는 시점
나경호(Na Gyeongho) edited this page May 27, 2025
·
1 revision
사용자가 유입되는 경로가 단순히 웹만 존재하지 않습니다. 안드로이드와 애플이 존재하며, 심지어는 멀티 디바이스로 유입될 수 있습니다.
그렇기 때문에 첫 로그인(회원가입) 시점에만 푸시알림 여부를 받을 경우 모든 환경(기기)에 푸시알림 여부가 동일하게 적용됩니다.
따라서 각 환경(기기) 별로 푸시알림 여부를 받아야 합니다.
- TODO
-
기획 확정되면 웹에서 백그라운드 알림을 제공할 건지 물어보기
⇒ 이에 따라 fcmToken으로 푸시알림 여부를 관리하는 것이 아닌 fcmToken + 환경으로 푸시알림 여부를 관리해야할 수도? → 아닌듯 웹과 앱의 토큰 환경이 분리되어 있는듯
-
- 로그인 후 특정 환경(기기)에서 첫 로그인인지 판단
- 첫 로그인인지 아닌지 클라에게 응답
- 클라가 해당 응답을 바탕으로 푸시알림 API 호출하거나 미호출
- (재로그인 시 → ?)
각 환경의 첫 로그인에서 FcmToken을 저장하므로 그때 푸시알림 여부를 받음
- 로그인 요청: FcmToken 추가
- 로그인 응답: 첫 로그인인지 아닌지
- 로그인 응답에 따라, 첫 로그인이면 사용자에게 푸시알림 여부를 묻고 해당 데이터와 함께 푸시알림 API 호출
- 로그인 요청: FcmToken 추가
- 로그인 응답: 첫 로그인인지 아닌지
- 로그인 API: 특정 환경에서 첫 로그인인지 판단 (토큰이 DB에 없는지)
- 푸시알림 여부 받는 API 추가
- 푸시알림 여부 저장 테이블을 User → UserDevice 변경
- 백엔드 컨벤션
- TestContainer 적용 이유
- DB Read replica 구성 (AWS RDS)
- RDS 프라이빗 설정 후 로컬 터널링
- 공통 성공/에러 응답 정의
- 테스트 환경 통합 작업
- 소셜 로그인 설계(Spring Security 없이 OAuth2.0)
- 클라우드 환경변수 관리 AWS SSM Parameter Store
- 코드단 제안 사항 (카카오톡 내용 요약)
- Spring에서 JWT 인증/인가 위치 제안(Filter와 Interceptor)
- 알림 아키텍처 정리
- 외부 API Call 및 무거운 작업 Serverless Lambda 로 분리
- Redis GEO (유저 위치 저장 및 검색)
- 푸시알림 권한 받는 시점
- TestConfig 및 (이전) Fixture 활용 방법
- 테스트 코드 개선 제안: Mock과 Fixture 패턴
- 테스트 객체 자동 생성
- 푸시알림 설계
- Fixture 및 Factory 활용 방법
- 로그 모니터링 시스템 구축
- 성능테스트 케이스