혼합 아키텍처

REST 와 WebSocket 을 함께 쓰는 것이 흔한 운영 패턴이야

가장 흔한 운영 아키텍처는 ‘WebSocket 만’ 쓰는 형태가 아니야. CRUD 는 REST, 실시간 갱신은 WebSocket 이 맡아. 채팅 메시지를 /api/messages 에 POST 하면 REST 처리기가 저장하고 WebSocket 으로 펼쳐. 다시 연결한 클라이언트는 GET /api/messages?since=X 로 기록을 가져온 뒤 WebSocket 으로 새 메시지를 받아.

SSE 와 WebSocket 을 함께 쓰는 AI 시대의 패턴

일방향으로 토큰을 자주 보내는 AI 전송과 양방향 상호작용을 함께 가진 앱이라면 답변 전송에는 SSE, 나머지에는 WebSocket 을 쓸 수 있어. cwkPippa 가 이 경계에 있어. 채팅 답변은 SSE 로 흐르고 Council 선택과 관리 작업은 REST 를 거치며, WebSocket 하나가 접속 상태와 알림을 운반해. 세 전송 방식을 각자 잘하는 일에 배치한 거야.

Code

WebSocket 전체 전송을 일으키는 REST 엔드포인트·python

from fastapi import FastAPI, Depends
from pydantic import BaseModel

class CreateMessage(BaseModel):
    room: str
    text: str

@app.post('/api/messages')
async def create_message(payload: CreateMessage, user = Depends(auth)):
    saved = await db.messages.insert({
        'room': payload.room,
        'text': payload.text,
        'from': user['id'],
    })
    # Source of truth is the database;
    # WebSocket is the liveness layer over it.
    await ws_manager.broadcast(payload.room, {
        'type': 'chat.message',
        'data': saved,
    })
    return saved

아키텍처 구성도·text

  Client
    |
    +-- POST /api/messages -----> REST API ----> Database
    |   (send a message)              |
    |                                  v
    +-- WS (subscribe room) <------ Manager broadcasts to room
    |   (receive others' messages)
    |
    +-- GET /api/messages?since=X -> REST API
        (history on reconnect)

Exercise

이전 채팅 실습 중 하나를 골라 메시지 전송이 WebSocket 대신 영속화와 전체 전송을 맡는 POST /api/messages 를 거치도록 고쳐. 다시 연결한 클라이언트가 GET /api/messages 로 기록을 가져온 뒤 끊김 없이 계속할 수 있는지 확인해. 없어진 코드를 살펴보면 WebSocket 처리기가 더 작아져 있어야 해.

REST 와 WebSocket 을 함께 쓰는 것이 흔한 운영 패턴이야

SSE 와 WebSocket 을 함께 쓰는 AI 시대의 패턴

Code

External links

Exercise

Progress

댓글 0