WebSockets 대신 Server-Sent Events 사용하기
(germano.dev)- 실시간 웹 어플리케이션을 만들때 보통 웹소켓이 생각나겠지만 SSE도 간단한 대안이 될 수 있음
- 웹 소켓의 문제점 : HTTP 기반이 아니기 때문에 HTTP의 수혜를 받지 못함
ㅤ→ 압축 불가, HTTP/2 멀티플렉싱 지원 미비, Proxy 들이 지원 안함, 하이재킹 가능
- Server-Sent Events(SSE)
ㅤ→ 서버가 클라이언트에게 Low-Latency 푸시 이벤트를 보낼 수 있는 기능
ㅤ→ HTML 표준이고 모든 브라우저가 지원함(IE 제외)
ㅤ→ 웹소켓과 다르게 SSE는 서버에서 클라이언트 한 방향으로 흐름 (양방향 통신이 필요한 게임에는 맞지 않음)
ㅤ→ HTTP 위에서 동작하며 별도 프로토콜이 필요 없음
Load Balancer나 Proxy 환경에서는 SSE지원이 부족한 경우가 많습니다. (+Enterprise Firewall)
Cloudflare나 AWS CLB 등등의 환경을 고려하신다면, SSE를 도입하기 전에 한번 더 확인해보셔야합니다.
GraphQL Subscription 을 위한 Transport 로 WebSocket 대신 활용되는 경우도 있습니다.
- GraphQL SSE 핸들러 구현: https://github.com/enisdenjo/graphql-sse
- SSE를 Subscription transport로 활용하는 예시: https://www.graphql-yoga.com/docs/features/subscriptions
Deno Deploy나 Lambda 같은 특수한 환경에서 웹소켓을 구현하기 어려울 때 대안이 될 수 있습니다. :-)
저도 최근에 Deno Deploy에서 채팅 예제를 보다가 SSE를 처음 알게되었습니다.
https://github.com/lucacasonato/deploy_chat
이 글의 댓글과 HN의 댓글도 같이 참고하세요.
SSE를 사용중인 사람들과 웹소켓에서 전환한 사례, SSE로 갔다가 다시 웹소켓으로 돌아간 사례 등등 다양한 의견이 많네요
https://news.ycombinator.com/item?id=30312897
사실 글에서는 SSE의 장점을 많이 얘기하긴 합니다만, 특별한 시나리오에서만 유용하긴 합니다.
요즘은 웹소켓쪽도 라이브러리가 많이 나와서 구현이 더 간단해 지기도 했고요.
- 웹 소프트웨어의 미래는 HTML-over-WebSocket 이다 https://news.hada.io/topic?id=3818
이런 주장도 있습니다.