Hacker News 의견

• Long polling은 자체적인 문제를 가지고 있음

  • Second Life는 클라이언트와 서버 간에 HTTPS long polling 채널을 사용함
  • 클라이언트 측에서는 libcurl을 사용하며, 타임아웃이 발생할 수 있음
  • 서버가 타임아웃과 다음 요청 사이에 메시지를 보내려 하면 경합 조건이 발생하여 메시지가 손실될 수 있음
  • Apache 서버가 앞단에 위치하여 불필요한 요청을 차단하지만, 타임아웃이 발생할 수 있음
  • 중간 박스와 프록시 서버가 long polling을 싫어할 수 있음
  • HTTP 연결을 오래 유지하는 것을 싫어하는 요소들이 많음
  • 결과적으로 신뢰할 수 없는 메시지 채널이 되어 중복을 감지하기 위해 시퀀스 번호가 필요하고 메시지를 잃을 수 있음
  • 원래 기사에서 "loop"로 표시된 차트 섹션은 타임아웃 처리를 언급하지 않음
  • long polling을 사용할 경우 몇 초마다 데이터를 보내 연결을 유지해야 함

• Phoenix와 LiveView를 매일 사용하는 것이 기쁨

  • WebSockets를 사용하여 신경 쓸 필요가 없음

• 서버 전송 이벤트(SSE)를 사용하는 것보다 기술적인 이점이 있는지 궁금함

  • 둘 다 HTTP 연결을 열어두고 간단한 HTTP라는 장점이 있음
  • SSE는 업데이트나 결과를 스트리밍할 수 있는 경우에 더 적합해 보임
  • 적합한 사용 사례는 특정 클라이언트를 대신하여 모든 작업 ID를 모니터링하는 경우일 수 있음

• 이 기사는 "Websocket"과 "Long-polling"을 독립적인 결정으로 연결하고 있음

  • long-polling 서버는 약간의 추가 작업으로 websocket 클라이언트를 처리할 수 있음
  • 기존 아키텍처가 websocket인 경우 long-polling 클라이언트를 지원하려면 두 개의 서버 계층이 필요함

• Node.js에서 setTimeout을 사용하는 더 쉬운 방법

  • import { setTimeout } from "node:timers/promises"; await setTimeout(500); 사용

• long polling을 좋아함, 이해하기 쉽고 클라이언트 관점에서 매우 느린 연결처럼 작동함

  • 재시도와 클라이언트 측 취소된 연결을 추적해야 함
  • 코드 예제에서 반복적으로 데이터를 쿼리하는 루프가 어색해 보임

• 서버 전송 이벤트나 WebSockets가 long polling의 모든 사용 사례를 대체하지 못함

  • SSE의 연결 제한이 자주 문제로 등장함
  • WebSockets는 대부분의 환경에서 신뢰할 수 없음
  • 백엔드에서 변경 사항을 감지하고 적절한 클라이언트로 전파하는 문제는 여전히 해결되지 않음

• Postgres의 비동기 알림 기능을 사용하는 것이 좋음

  • 서버가 채널을 LISTEN하고 데이터 변경 시 PG가 TRIGGER 및 NOTIFY할 수 있음

• 짧은 타임아웃과 우아하게 종료된 요청을 가진 long polling의 의미가 여전히 있는지 모르겠음

  • HTTP/2나 QUIC이 사용되지 않는 경우 이 트릭이 여전히 의미가 있을 수 있음

• WebSockets의 상대적으로 간단한 대안을 상기시키는 것이 상쾌함

  • WebSockets를 선택한 스타트업에서 일했었고, 호텔과 레스토랑 와이파이에서 테스트가 어려웠음