proxy.ts, Route Handler, custom server - 무엇을 어디에 둘까
요청을 가로채 백엔드로 넘기는 자리가 Next.js에는 셋이다. proxy.ts로 충분한 경우, Route Handler가 필요한 경우, custom server까지 가야 하는 경우를 두 프로젝트의 선택을 놓고 갈랐다.
// 가독성과 탐색성을 우선으로, 구현 메모와 기술 문서를 차곡차곡 쌓아가는 프론트엔드 블로그.
Tag
9개의 글이 연결되어 있습니다.
요청을 가로채 백엔드로 넘기는 자리가 Next.js에는 셋이다. proxy.ts로 충분한 경우, Route Handler가 필요한 경우, custom server까지 가야 하는 경우를 두 프로젝트의 선택을 놓고 갈랐다.
SharedWorker는 최초 연결의 baseURL로 SSE가 고정된다. k8s 스코프를 추가하자 먼저 연 탭의 스코프로 전체가 고정되는 문제가 생겼다 - 워커 이름을 파티셔닝 키로 쓰고, 프록시는 catch-all 라우트 하나로 합친 과정.
payload는 알림 모달에겐 순수 트리거, Host/Container 테이블에겐 부분 업데이트의 조준 정보다. 화면에 그리는 데이터는 언제나 API pull - refreshSignal의 생산→전달→소비 설계까지.
docker와 k8s가 같이 쓰는 host 목록 화면. 그런데 공유 구현이 docker/host에 있으면서 k8s 도메인을 직접 import하고 있었다. docker가 k8s를 아는 역방향 의존 7건을, 계약(HostExtension)만 남기고 도메인 조각을 주입하는 방식으로 0건까지 끊은 기록.
한 세션 동안 모노레포의 폴더/의존성 구조를 존(zone) 단위로 재정리했다. 단순한 git mv처럼 보이지만 repoint 스코프 누락, alias 이름 함정, zsh 단어분할, tsc 동시 실행 thrash까지 사고가 끊이지 않았다. 매 단계 tsc 에러 수를 baseline으로 두고 깨지면 되돌린 작업 일지.
store 설정 파일이 두 개로 갈라져 있고, selector 위치가 사람마다 다르고, slice 확장자가 섞여 있었다. 실제 프로젝트의 Redux 구조를 진단하고 리팩터링 방향을 정리한 기록.
Modal이 많은 도메인에서 Config을 어떻게 짤지 두 가지 패턴을 비교했다. 정적 Map과 Factory Map의 차이는 결국 Controller의 역할을 어디까지로 정의할 것인가의 문제였다.
kubectl apply 한 번이 어떻게 컨테이너 실행으로 이어지는가. Control Plane의 4개 컴포넌트와 Worker Node의 3개 컴포넌트가 각각 어떤 역할을 맡고, 어떻게 협력하는지 정리한다.
실시간 알람 시스템을 SSE와 Shared Worker로 구축하면서 실제로 고민했던 것들 — Next.js Edge Runtime 문제, 배치 전략 설계, 재연결 정책, 탭 간 상태 동기화까지.