"트래픽 모양으로 트랜스포트를 골라. Rekindle 은 백엔드가 계속 읽어야 할 게 없어 — 그래서 순수 HTTP 가 이겨."
트랜스포트를 트래픽에 맞춰
WebSocket 은 지속적, 양방향 파이프야 — 강력하고, 순수 HTTP 보다 돌리고 추론하기 복잡해. 맞는 질문은 '어느 게 더 화려해' 가 아니라 '트래픽 모양이 뭐야' 야. Rekindle 트래픽은 단순해. 메시지를 보내면 스트림 응답을 받고; 텍스트를 선택하면 one-shot 재작성을 쏴. 에디터에서 백엔드로 계속 흐르는 건 없어. 그래서 Rekindle 은 bind 는 REST, 스트림은 SSE — cwkBonfire 가 쓰는 그 embed 모델 — 를 쓰고 WebSocket 을 통째로 건너뛰어.
왜 Cinder 는 WebSocket 이 필요하고 Rekindle 은 아닌가
Cinder 와의 대조가 레슨 전부야. Cinder 는 Photoshop 옆에 타는데, 그 UXP 플러그인이 백엔드가 읽어야 할 상태를 계속 push 해 — 진짜 producer leg, 지속 소켓을 정당화하는 상시 상류 흐름. Rekindle 은 producer leg 이 없어. 문서 맥락은 매 턴 push 지 계속 스트림 아니고; 백엔드가 계속 읽어야 할 라이브 피드가 없어. 같은 가족, 다른 트래픽 모양, 올바르게 다른 트랜스포트.
표면 상류 흐름 트랜스포트
------- --------------------------- ----------------------
Cinder Photoshop 이 계속 push WebSocket (producer leg)
Rekindle 메시지, 그다음 응답 REST (bind) + SSE (스트림)
# 지속 producer 없음 -> WebSocket 없음. 순수 HTTP 가 맞는 크기.
bind 는 REST, 스트림은 SSE
구체적으로: REST 호출이 문서를 대화에 bind 하고 턴을 보내고; 응답이 SSE 로 토큰별로 스트림돼, cwkPippa 자기 채팅이 하는 그대로. CMD+K 는 더 단순해 — 재작성을 반환하는 단일 POST. 둘 다 순수 HTTP 에 완벽히 맞아. 충분한 더 작은 트랜스포트를 고르는 건 소심함이 아냐. 충분한 가장 작은 레이어를 빌리고 (트랙 3) 기존 엔진을 재사용하는 (트랙 5) 같은 규율이야. 요청-그리고-스트림이 이미 섬기는 트래픽에 지속 소켓을 돌리지 마.