Hacker News 의견
  • Mercure는 SSE 기반의 오픈 프로토콜로, WebSockets 기반 솔루션의 대체물로 사용됨. Mercure는 클라이언트와의 지속적인 SSE 연결을 유지하는 독립적인 허브를 중심으로 작동하며, 서버 앱과 클라이언트가 사용할 수 있는 간단한 HTTP API를 제공함. Mercure는 JWT 기반의 인증 메커니즘, 여러 주제에 대한 단일 연결 구독, 이벤트 기록, 네트워크 문제 발생 시 자동 상태 조정 등의 기능을 추가함

  • SSE의 큰 단점은 HTTP/2가 아닌 경우 최대 연결 수 제한이 있다는 점임. 이는 브라우저당 제한이 낮아 여러 탭을 열 때 문제가 될 수 있음

  • Doppler의 CLI에서 SSE를 사용하여 자동 재시작 기능을 구현했음. SSE를 통해 서버에서 이벤트를 수신하고 최신 비밀 정보를 가져와 애플리케이션 프로세스에 주입함. WebSockets 대신 SSE를 선택한 이유는 Golang 애플리케이션에 추가 종속성을 가져오지 않기 위함임. HTTP 타임아웃 문제를 해결하기 위해 간헐적인 "ping" 이벤트를 전송해야 했음

  • SSE의 단방향 특성은 제한적으로 보일 수 있지만 많은 경우에 충분함. SSE의 주요 제한 사항은 텍스트 전용이라는 점과 HTTP/1.1에서의 브라우저 연결 제한임. HTTP/2 이상을 사용하면 연결 제한은 문제가 되지 않음. 성능이 중요한 경우 fetch와 ReadableStream을 사용하여 더 유연하고 오버헤드가 적은 솔루션을 선택할 수 있음

  • SSE의 단순성 때문에 많은 개발자가 적절한 구현을 사용하지 않고 데이터 청크를 정규 표현식으로 파싱하는 경우가 많음. 이는 SSE가 스트림에서 주석을 지원하기 때문에 문제가 될 수 있음

  • Data-star.dev는 SSE를 통해 하이퍼미디어 응답을 스트리밍하는 데 중점을 둔 프론트엔드 라이브러리임. Go와 NATS를 백엔드 기술로 사용하여 개발되었으며, 모든 SSE 구현과 호환됨

  • SSE는 과소평가되지 않음. 실제로 Open AI에서 스트리밍 완료에 사용되고 있음. ReactJS 코드베이스에서 SSE를 구현하는 것은 어려웠으며, 당시 Axios가 이를 지원하지 않아 네이티브 fetch를 사용해야 했음

  • 웹 프로젝트에서 SSE를 구현했을 때, 6개 이상의 탭을 열면 웹사이트가 작동을 멈췄음. Firefox는 SSE 연결을 6개의 호스트 최대 연결 제한에 포함시키며, 이로 인해 추가 요청이 차단됨

  • SSE는 잘 작동할 때 과소평가됨. 현재 작업 중인 프로젝트에서 인증 문제와 터널의 keep-alive 문제로 인해 어려움을 겪고 있음. 이는 프로토콜의 문제가 아니며, 해결책을 찾는 것이 어려움