-
Notifications
You must be signed in to change notification settings - Fork 4
06 ‐ 08 ‐ Notification 모듈
Ryu(Paul) edited this page Feb 9, 2024
·
1 revision
- 비즈니스 요구사항
- 아키텍처 설계
- API 엔드포인트 설계
- 다른 모듈과 상호작용 포인트
- 온라인 상태에서 각각의 행동에 맞춰서 알람을 전달해준다.
- 오프라인 상태에서는 PWA를 통해 실시간에 가깝게, 개인화된 설정에 따라 알림 메시지가 전달된다.
- 알림의 유기적 연계를 통해, 온-오프라인 상황에서 전달되는 알람이 사용자 경험을 해치지 않으면서 적절하게 생성, 전달, 삭제가 되어야 한다.
- 주 서버 : 'spring boot' 기반의 서버
- 부 서버 : 'NestJS' 기반의 서버
- 프록시 : NGINX 로 구현된 서버끼리 소통을 위한 프록시 서버
- 각 모듈에서 알람이 필요시 간단하게 등록이 가능하다.
- 온라인, 오프라인 상태를 파악하고, 이에 따라 알람을 PWA로 전달할지 여부를 정하고 전달이 가능하다.
- 긴급도에 따라 선택적으로 전달 여부가 파악되며, 여기서 사용자의 알림 설정 동의 여부를 파악해 전달이 가능하다.
- 알람 개별의 삭제를 지원한다.
- 알람 전체 삭제를 지원한다.
- 알람을 유저 한명에게 전달이 가능하다.
- 알람을 특정 유저에게 전달이 가능하다.
- 알람을 전체 유저에게 전달이 가능하다.
- 알람을 유저에게 전달할 때, 페이지네이션이 지원 된다.
- 주 서버에서 알림 이벤트 발생에 대하여 처리 후, 이를 부 서버에 알리며, 프록시는 이 요청과 결과를 반환해줄 수 있도록 지정된다.
- (PWA) 알림이 전달되고, 사용자가 하드웨어에서 리다이렉션이 이루어지면, 알람 데이터베이스에서 해당 알람이 자동 삭제가 되어야 한다.
- (PWA) 유저가 구동을 승인하면, 이에 대응하여 주 서버에서 해당 목록에 사용자ID와 pwa를 위한 키를 등록할 수 있다. (중복 등록이 허용된다.)
- (PWA) 유저가 구독을 취소하면, 이에 대응하여 주 서버에서 해당 목록에서 대상을 삭제한다.
- 구현 후 고민할 예정
- app.js
- manifest
- HTTPS 환경
- HTTPS 환경 : PWA 표준을 지키기위한 HTTPS 표준 보안 키 발급 및 적용
- 프론트 엔드 : 구성 완료
- 백 엔드(주 서버) : 구성 완료
- (예정) 백 엔드(부 서버) : CICD 이후 구성 예정
- PWA proxy 설정 : client에서 PWA 구독과 함께, 앱 알림, 구독하여 백그라운드 동기화가 있을시 동작 할 수 있도록 설정한다. 구성 예정
- 주-부 서버 proxy 설정 : 백엔드 서버 간의 통신을 위한 설정 구성 예정
- Socket Gateway : 사용자 온라인 여부를 추적하기 위한 소켓을 활용한 헬스 체크용도
- Socket Service : 사용자 온라인 여부를 의존성 주입을 통해 사용할 수 있다.
- Alarm Controller : 알람의 API 를 맵핑한 컨트롤러
- Alarm Control Service : 알람의 제어, 부 서버와의 통신 등을 담당한다.
- Alarm CRUD Service : 알람의 작성, 데이터베이스와 관련된 작업들을 담당한다.
- Alarm Controller : PWA 관련된 기능과, 주서버에서 전달하는 통신을 수신하는 역할을 한다.
- Alarm Service : DB 읽기 접근을 하고, PWA 앱 푸시 기능을 담당한다.
- Alarm-List Table : 실제 작성된 알람 데이터
- Alarm-Deleted-All Table : 알람 중
전체 공지사항
인 알람에서, 삭제를 요청받은 경우 관리를 위해 기록하는 용도, 특정 알람이 전체 공지사항일 때, 해당 테이블에 삭제를 요청한 사람의 데이터 수가 가득 차면, 그때 해당 공지사항 메시지가 삭제 된다. - Alarm-subscription Table : PWA 구독시 발생하는 키와 내용을 담는 테이블
- push server DTO : 푸시 서버에 보내야 할 것들
- title : 알람 제목
- body : 알람 본문
- icon : 알람 표시용 아이콘의 URL
- badge : 알림 배지에 사용될 작은 아이콘 URL
- data : 추가 데이터를 포함할 수있는 객체(URL, 알림 관련 기타 정보 등)
- dir : 텍스트 방향 지정
- lang : 알림 언어
- tag : tag 알림 그룹화용 식별자
- vibrate : 진동 패턴 정의 숫자 배열
-
AlarmListnotification
- id : LONG, 알림 이벤트에 대한 고유 키
- title : String, 메시지 제목
- message : String, 메시지 본문
- targetType : Enum, 메시지 종류(전체, 일정 부분)
target : List, userId 리스트, 대상목록을 가리키며, 전체 메시지인 경우 null 이 된다.- List targets : 대상 목록
- linkData : String, 리다이렉션을 위한 URL 데이터
- sended : Enum, PWA로 보내졌는지 여부 확인용
- priority : Enum, 우선순위를 통해 스케쥴링, 강제우선, 당장 보내야 하는 것을 구분하는 용도
- immediate : 사용자의 동의여부에 근거하여 메시지를
즉시
전달한다. - scheduled : 사용자의 동의여부에 근거하여 메시지를
일정하게
전달한다. - force : 사용자의 동의여부에 근거하지 않고 메시지를
즉시
전달한다.
- immediate : 사용자의 동의여부에 근거하여 메시지를
- messageType : String 알림의 Tag 기능을 할 예정
- scheduledTime : 예상되는 전달 시간, 입력시 한국 기준으로 넣고 내부 동작은 UTC 기준으로 진행되어야 한다.
- totalCount : Long, 알람을 보내야할 전체 인원수를 지정한다.
- deleteCounter : Long, 전체 또는 1명 초과의 알람의 경우 삭제 요청이 올 경우, 여기에 카운팅 된다.
- createdAt(BaseEntity)
- updatedAt(BaseEntity)
-
AlarmDeletedAllnotification-target
id : AlarmId + UserId : 복합키로 생성하는 ID, 삭제 요청이 왔을 경우 기록하는데 사용한다.alarmId : 연결되는 알람과 연결시킴- id
- notificationId
- userId
-
AlarmSubscriptionnotification-subscription
- id : 고유키
- userId : 사용자 계정
- subscriptionKey : 구독하는데 사용되는 고유 키
- createdAt(BaseEntity) : 생성날짜만 등록
- 쪽지 알림
- 스터디 / 프로젝트 승인 알림 & 거절 알림
- 스터디 / 프로젝트 참여 신청 알림 & 취소 알림
- 스터디 / 프로젝트 종료 알림
- 피어로그 & 쇼케이스 작성 알림
- 팀 페이지 공지 업데이트 알림
- 관심 키워드 알림
- 피어로그 & 쇼케이스 작성 알림
- 쇼케이스 '좋아요', '댓글' 알림
- 운영팀 공지
- 운영팀 공지
- 수동 알림
- 유저가 회원가입을 통해 계정 생성이 이루어진다.
- 유저에게서 알림에 해당하는 이벤트가 발생한다.
- 해당 이벤트를 담당하는 모듈에서 DI 되어 있는 알람모듈에서 알람을 작성한다.
- 유저가 온라인 상태를 확인하면 PWA 로 전달하지 않으며, 알림 메시지 DB에 저장만 이루어진다. (이때 scheduled, force는 무조건 PWA로 진행된다)
- 유저가 알람을 요청하는 API를 호출하게 되는 경우, 해당 요청에 해당하는 메시지를 전달한다.
- 유저에게 메시지가 전달되면 sended 에 true로 바뀌며 메시지가 update 된다.
- 알람 리스트에서 삭제가 발생한다.
- 전체 삭제 API가 호출되면서 DB를 비운다.
- 성공 했음을 전달하고 마무리 시킨다.
- 알람 리스트에서 삭제가 발생한다.
- 삭제하는 대상에 대해 파악을 하고(id) 해당 삭제를 진행한다.
- 성공 했음을 전달하고, 새로운 리스트를 갱신하여 전달한다.(이때 프론트엔드는 의도적으로 로딩시간을 추가한다)
- 요청이 들어온 삭제의 이벤트가 하나의 유저를 위한게 아닌것이 검증되면
- 전체 알람인 경우에 AlarmDeletedAll 테이블에 해당 내용을 기록한다.
- 일부 알람인 경우에는 AlarmDeletedAll 테이블에 해당 내용을 기록하지는 않는다. 대신 List 에서 해당하는 userId를 삭제한다.
- deleteCounter를 증가 시킨다.
- 이때 deleteCounter == totalCount 인 경우 해당 알람을 삭제하고, 전체 알람시 AlarmDeletedAll 테이블의 대상이 있다면 이 역시 삭제한다.
- 알림이 필요한 이벤트가 발생하고, 알림이 생성된다.
- 유저가 오프라인 상태가 되었다는 것을 파악한다.
- 주서버에서 부서버로 알림에 대한 처리를 요청한다. 이때, 해당 관련하여 어디서부터 어디까지의 이벤트 처리를 해놓아야 하는지를 전달한다(알람 Id의 리스트?)
- 부서버는 DB를 일괄 읽어서, 처리해야하는 것들만을 모두 분석 한다. 이에 대한 리스폰스를 전달하면서 이에 대해 작업을 진행한다.
- 작업을 마치면 아이들 상태로 돌아간다.
- 주 서버는 리스폰스 값을 받은 뒤, 만약 사용자가 리다이렉션을 통해 지정된 link로 가게 된다면 request를 통해 pathvalue 를 기존 URL 뒤에 붙여주며, 주 서버는 이를 커스텀 어노테이션을 통해 인지. 이미 redirection으로 알람을 수령했으므로 DB에서 알람을 삭제한다.
- 고민중
- 알림 삭제 요청 시 보안 문제는 없는지? (JWT, 온라인 여부 등을 종합 고려할 것, 비동기 처리 필요할지도?)
웹 푸시 알림을 위한 각 서비스의 특징과 비용을 다음과 같이 정리할 수 있습니다:
- 특징: Android, iOS, 웹 기기를 통해 푸시 알림을 보내는 기능을 제공합니다. 크로스 플랫폼 솔루션으로, 다양한 운영 체제와 장치를 지원합니다 (출처).
- 비용: Firebase Cloud Messaging은 완전히 무료로 사용할 수 있습니다 (출처).
- Free Plan: 제한된 개인화, 무제한 API 전송, 지능적인 배송, A/B 테스팅, GDPR 준수 기능 제공 (출처).
- Growth Plan ($9/월 시작): 표준 개인화, 고급 인앱 메시징, 메시지 제한, 확인된 배송 등을 추가로 제공 (출처).
- Professional Plan ($99/월 시작): 고급 개인화, 저니 접근, CSV 내보내기, 사용자 정의 결과 추적 등을 추가로 제공 (출처).
- Enterprise Plan: 맞춤 계약 및 추가 기능, 볼륨 기반 할인 제공. 고급 개인화, 사용자 정의 계약, 온보딩 및 지원, 고급 사용자 권한 등을 포함 (출처).
- 특징: 미리 정해진 최소 약정이나 장기 계약 없이 사용한 만큼만 비용을 지불합니다 (출처).
- Standard topics: 월간 API 요청 수와 다양한 엔드포인트로의 배송 수에 기반한 요금제 (출처).
- FIFO topics: 발행된 메시지 수, 구독된 메시지 수, 각각의 페이로드 데이터 양을 기반으로 한 요금제 (출처).
- 메시지 필터링: 속성 기반 메시지 필터링은 무료이며, 페이로드 기반 필터링은 전송된 페이로드 데이터 양에 따라 비용이 부과됩니다 (출처).
- 메시지 보관 및 재생: 저장된 데이터 양과 저장 기간에 기반한 요금제 (출처).
- 메시지 데이터 보호: 검사된 페이로드 데이터 양과 생성된 감사 보고서 데이터 양에 따라 비용이 부과됩니다 (출처).
- 전 세계 SMS: 200개 이상의 국가에 SMS 메시징을 제공합니다. 전송 요금은 목적지 국가에 따라 다르며, 일부 국가에서는 전송을 위해 전용 발신자 ID를 구입해야 할 수도 있습니다 (출처).