C.W.K.
Stream
Lesson 02 of 04 · published

WebSocket 말고 REST + SSE

~11 min · rest-sse, websocket, transport, producer-leg

Level 0식은 초고
0 XP0/33 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"트래픽 모양으로 트랜스포트를 골라. 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) 같은 규율이야. 요청-그리고-스트림이 이미 섬기는 트래픽에 지속 소켓을 돌리지 마.

Code

bind 하고 보내는 REST; 응답 스트림 SSE·typescript
// 순수 HTTP 로 bind + 턴 보내기 (지속 소켓 없음).
const res = await fetch(`/api/chat`, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ conversationId, message, hostContext }),
});

// 응답이 Server-Sent Events 로 토큰별로 스트림돼 —
// cwkPippa 자기 채팅이 쓰는 그 스트리밍.
for await (const event of readSSE(res.body)) {
  appendToken(event.data);
}

// CMD+K 는 더 단순: 재작성 하나를 반환하는 단일 POST.
// 여기 아무것도 WebSocket 이 필요 없어, 상류로 스트림하는 게 없으니까.

External links

Exercise

세 기능 — 라이브 커서 공유 협업 뷰, 스트림 응답 채팅, one-shot '이거 요약해' 버튼 — 각각 어떤 트랜스포트가 필요한지 정해. 어느 게 producer leg (상시 상류) 을 가져 WebSocket 을 정당화하고, 어느 둘이 REST + SSE 로 괜찮은지 짚어. producer-leg 테스트가 셋 다 어떻게 정하는지 봐.
Hint
라이브 커서 공유는 위치를 상류로 계속 스트림 → WebSocket. 스트림 채팅은 요청-그리고-아래로-스트림 → SSE. one-shot 요약은 단일 요청/응답 → 순수 REST. 첫째만 producer leg 이 있고, 나머지 둘은 소켓이 필요 없어.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.