SharedWorker는 이름이 인스턴스다 - docker/k8s 스코프 분리
SharedWorker는 최초 연결의 baseURL로 SSE가 고정된다. k8s 스코프를 추가하자 먼저 연 탭의 스코프로 전체가 고정되는 문제가 생겼다 - 워커 이름을 파티셔닝 키로 쓰고, 프록시는 catch-all 라우트 하나로 합친 과정.
// 가독성과 탐색성을 우선으로, 구현 메모와 기술 문서를 차곡차곡 쌓아가는 프론트엔드 블로그.
Tag
12개의 글이 연결되어 있습니다.
SharedWorker는 최초 연결의 baseURL로 SSE가 고정된다. k8s 스코프를 추가하자 먼저 연 탭의 스코프로 전체가 고정되는 문제가 생겼다 - 워커 이름을 파티셔닝 키로 쓰고, 프록시는 catch-all 라우트 하나로 합친 과정.
백엔드 스펙엔 'JWT 헤더 필수', 브라우저 API엔 헤더 옵션이 없다. SSE 인증의 3가지 선택지와 협의 과정, 그리고 상태코드가 안 보이는 EventSource의 사각지대를 진단용 fetch로 메꾼 트릭.
콘솔에 '재연결 성공'이 끝없이 찍힌다. 백엔드의 401을 프록시가 200 SSE로 포장하면서 EventSource 내장 재연결이 무한 반복된 원인 사슬과, 상태코드 passthrough + 백오프 일원화로 수렴시킨 과정.
payload는 알림 모달에겐 순수 트리거, Host/Container 테이블에겐 부분 업데이트의 조준 정보다. 화면에 그리는 데이터는 언제나 API pull - refreshSignal의 생산→전달→소비 설계까지.
탭 10개를 열어도 서버 연결은 1개. SharedWorker + SSE 구조의 개발 루프에서 만난 함정들 - HMR 불가, 분리된 콘솔, 상태코드 은닉, 그리고 '모르면 건드리지 않는' 3값 판정.
SSE payload에 일련번호가 없는 알람이 발견됐다. 서버 필드 의존을 버리고 클라이언트 수신 시각으로 전환한 과정과, 옛 localStorage 값을 '판별 없이' 청소한 키 리네임 마이그레이션까지.
실시간 알람은 SSE를 골랐는데, 클러스터 설치 상태 화면에서는 Short Polling을 골랐다. 같은 '서버 → 클라이언트 실시간' 문제인데 왜 선택이 달랐는지 정리했다.
polling의 한계를 넘어 서버가 클라이언트에 이벤트를 흘려보내는 가장 단순한 방법인 SSE를, 포맷·EventSource API·자동 재연결·HTTP/2와의 궁합·한계 관점에서 정리했다.
Next.js Proxy가 일반 HTTP rewrite에는 적합하지만 SSE와 WebSocket 같은 장기 연결에는 Route Handler, custom server, gateway 분리가 필요한 이유를 정리했다.
SSE로 수신한 알람을 SharedWorker에서 받아 배칭하고, FULL_REFRESH와 ROW_UPDATE 두 전략으로 분기해 React Query 캐시를 직접 업데이트하는 설계를 파헤쳤다.
실시간 알람 시스템을 SSE와 Shared Worker로 구축하면서 실제로 고민했던 것들 — Next.js Edge Runtime 문제, 배치 전략 설계, 재연결 정책, 탭 간 상태 동기화까지.
Server-Sent Events로 서버 → 클라이언트 단방향 스트리밍을 구현하는 방법과, Shared Worker로 탭 간 상태를 공유하는 방법을 정리했다.