SSE and WebSocket

[iamcscs]

Thank you for such a great project，I now use it to develop the backend of ChatGPT.，So I want to ask what SSE and WebSocket have implementation milestones?

[justrach]

Quick milestone update for SSE & WebSocket. Investigated the current state:

SSE: API exists, transport doesn't.

• `python/turboapi/sse.py` — `EventSourceResponse`, `ServerSentEvent`, `format_sse_event` all functional. PR test: re-enable TestWebSocket + add SSE wire-format coverage (#146) #162 adds 18 unit tests locking the wire format down.
• Zig HTTP server doesn't iterate `StreamingResponse.body_iterator()`, so SSE responses currently send empty bodies through the dispatch path.
• Real SSE = chunked transfer encoding in the Zig response-write path. Concrete implementation plan filed as feat(zig): chunked transfer encoding for StreamingResponse / SSE end-to-end #163.

WebSocket: same shape — API surface exists, no over-the-wire transport.

• `@app.websocket("/ws")` registers fine; the `WebSocket` class works in-process; PR test: re-enable TestWebSocket + add SSE wire-format coverage (#146) #162 re-enables and confirms the 4 API-surface tests pass.
• No `Connection: Upgrade` handling / handshake / frame parser in the Zig server.
• Tracked in zig runtime: real WebSocket support on current turboapi-core architecture #114 with the full task list (handshake, frame layer, lifecycle, Python↔Zig bridge).

Both are real work that needs Zig-side transport changes — multi-PR efforts each, not single commits. PR #162 lands the test/docs cleanup so the gap is observable in CI rather than hidden behind `--deselect` workarounds. The implementation work itself is queued in #163 (SSE) and #114 (WebSocket).

If you have a deadline / preference order between SSE and WebSocket for the ChatGPT use case, let us know — SSE is closer to ready (Python side fully done; just the Zig stream path) so it may ship first.

[justrach]

Status update — SSE is done end-to-end, WebSocket is queued.

SSE — shipping in #164

Real chunked-transfer streaming through the Zig HTTP server. Implementation:

• Python: `StreamingResponse.body_iter()` returns a sync iterator; async generators are driven one chunk at a time on the worker thread's event loop, so SSE / token streams flush in real time.
• Zig: new `sendStreamingResponse` writes `Transfer-Encoding: chunked` headers + custom headers (Cache-Control, X-Accel-Buffering, etc.), then loops `PyIter_Next` writing each chunk as `\r\n\r\n`, terminates with `0\r\n\r\n`.
• ABI: 5-tuple `(status, content_type, b"", iterator, headers)` for streaming; existing 3-tuple unchanged for non-streaming.

Wire-level proof (5-event SSE generator, async handler, 50ms between events):

• Before: all 5 events disappeared into an empty 200 response (Content-Length: 0).
• After: 5 chunks delivered at ~50ms intervals via real chunked transfer, TTFB 4ms, TTLB 259ms — flushing in real time, not pre-buffered.

CI tests: `tests/test_sse_e2e.py` boots a real subprocess server, hits it with httpx + raw socket, asserts wire-level behavior across 6 cases (chunked encoding, custom headers, real-time delivery, terminator framing, raw bytes generators, sanity ping). All pass.

WebSocket — queued for a follow-up PR

Real WS support requires a Zig-side frame parser (RFC 6455: opcodes, three payload-length encodings, client-mask XOR, fragmentation, ping/pong/close handling) plus the upgrade handshake and Python ↔ Zig bridge. That's tight bit-twiddling code best done in a focused session — rushing it after the SSE work invites subtle protocol bugs that unit tests catch slowly.

Tracked in #114 with the full implementation plan + the wire-level evidence from the earlier probe.

For your ChatGPT-style backend specifically: SSE (now shipping) covers the LLM token-streaming use case. WS would only be needed if you want bidirectional client → server messages mid-stream (e.g. "stop generation" button). If that's a hard requirement, please prioritize accordingly; otherwise SSE alone unblocks the main flow.

[justrach]

SSE implementation is tracked in #163 (chunked transfer encoding for StreamingResponse/SSE). The Python-side SSE helpers (EventSourceResponse, ServerSentEvent, format_sse_event) are already implemented in python/turboapi/sse.py with unit tests — what's missing is the Zig server-side chunked transfer encoding to actually stream the data.

WebSocket has a separate tracking issue.

Closing this as a duplicate of #163 for SSE. Thank you for using TurboAPI!

[justrach]

Tracked in #163 (SSE/chunked encoding). Closing as duplicate.