알림 구현 방식

웹 알림 구현 방식

Polling(클라이언트에서 주기적으로 알림 체크)

• 화면이 바뀔때마다 api를 호출해 알림이 있는지 확인하거나

• 주기를 설정하여 자동으로 api를 호출하여 알림이 있는지 확인

장점

• 구현이 비교적 간단함

• client - server 연결 상태에 대한 관리 부담이 없다.

단점

• 유저에게 전달할 알림이 없어도 api가 호출되기 때문에 자원 낭비가 될 수 있음
• 트래픽이 높은 서비스에는 부적합

Long-Polling(서버에서 주기적으로 알림 체크)

• client의 요청을 받은 서버는 응답으로 보내줄 새 알림이 없다면 응답을 보내지 않고 대기

• timeout 설정된 시간까지 새 알림이 없다면 응답을 보내고 client는 새로운 요청을 서버에 전송

장점

• 폴링 방식보다 비교적 효율적

단점

• 알림이 빈번하게 발생하면 폴링 방식이랑 별 차이 없음

• 클라이언트와 서버의 커넥션을 관리해야함
• 관리를 잘못할 경우 서비스 장애로 이어질 확률이 매우 높음
 

Web-socket

• 양방향 통신을 위해 개발된 기술인데 알림에 적합한가?

Server-sent Events

장점

• 알림 메커니즘과 가장 잘 어울림

• 기존 폴링의 성능적인 단점을 해결하면서 웹소켓보다 훨씬 가벼움

단점

• 클라이언트와 서버의 커넥션 관리문제는 여전히 존재

• 어느정도의 학습 곡선이 필요
• 프론트 : eventsource
• 백엔드 : SseEmitter

Ref

• SSE
[Spring + SSE] Server-Sent Events를 이용한 실시간 알림
코드리뷰 매칭 플랫폼 개발 중 알림 기능이 필요했다. 리뷰어 입장에서는 새로운 리뷰 요청이 생겼을 때 모든 리뷰가 끝나고 리뷰이의 피드백이 도착했을 때 리뷰이 입장에서는 공통적으로 위의 경우 알림을 보내줘야한다고 생각했다. 로그인한 상태가 아니라면 로그인 했을 때 받은 알림을 모두 보여주면 되지만, 로그인한 상태라면 실시간으로 알림을 받길 원했다.

https://velog.io/@max9106/Spring-SSE-Server-Sent-Events%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EC%8B%A4%EC%8B%9C%EA%B0%84-%EC%95%8C%EB%A6%BC