Server-Sent Events and Server-to-Client Streaming

_Locale: en-US · Lesson: WEB-007 · Public order: 51_

Outcome and working artifact

This lesson produces a SSE Resume and Delivery Evidence Record v1: a decision artifact that separates observations, assumptions, limits, and required evidence. The goal is a transferable model, not memorized tool names.

می‌تواند «SSE و Server-to-Client Streaming» را در یک feature محدود طراحی/پیاده‌سازی کند و correctness، accessibility یا failure behavior مرتبط را اثبات کند.

Boundary model

Server-Sent Events provide a browser-oriented, server-to-client event stream over HTTP. The simple API can hide the hard questions: event identity, reconnection, replay windows, duplicate handling, buffering intermediaries, cancellation, and user-interface state after a gap. This lesson treats SSE as at-least-repeatable evidence, not an exactly-once guarantee.

Keep three labels throughout the work: observed, bounded inference, and needs verification. When evidence is unavailable, record unknown. A product name or a passing happy path is not a substitute for evidence.

1. SSE is one-way

The server emits UTF-8 text events and the browser receives them. Client-to-server commands still need another HTTP request or another transport.

2. Framing is part of the contract

Fields such as event, id, data, and optional retry are line-based; a blank line terminates one event. Multi-line data and comments must be handled deliberately.

3. Event IDs support a resume protocol, not storage

The client can expose the last received ID during reconnection. The server still needs a retention and replay policy; Last-Event-ID does not create that policy automatically.

4. Duplicates and gaps are application concerns

Reconnect races can replay an event or miss data outside the retention window. A consumer view should be idempotent by stable event ID and should surface an unrecoverable gap.

5. Infrastructure can change observable behavior

Proxy buffering, connection limits, idle timeouts, compression, and deployment topology can affect latency and longevity. A local pass does not prove production behavior.

Five-step method

1. Define named event types, a stable event ID, data schema, heartbeat rule, and termination behavior.
2. Define the retention window and the response when the requested resume ID is too old or unknown.
3. Make the client reducer idempotent: ignore an already-applied ID and preserve monotonic progress where the domain requires it.
4. Force disconnect, duplicate replay, stale resume, malformed frame, and slow-consumer probes.
5. Record local evidence separately from deployment assumptions about buffering, timeouts, and connection capacity.

Worked case

A job emits progress events 41, 42, and 43. The client applies 41 and 42, disconnects, and reconnects with 42. The server replays 42 and 43. The UI ignores the duplicate 42 by ID and applies 43. A second probe reconnects with ID 10 after the replay window has expired; the server returns an explicit reset-required event rather than pretending continuity. This proves the local policy only; it does not prove that a production proxy will avoid buffering.

Decision and evidence matrix

Failure probes and repair

• SSE is bidirectional like WebSocket.
• EventSource plus id fields guarantees exactly-once delivery.
• Last-Event-ID makes the server persist missed events automatically.
• A local stream test proves proxies will not buffer or time out the connection.
• SSE is always preferable to polling or WebSocket.

For each statement, narrow the claim, create a counterexample, and name the observation that could confirm or reject it.

Transfer challenge

Change the scenario so that one assumption in the worked case no longer holds. Rebuild the SSE Resume and Delivery Evidence Record v1 without copying the earlier decision, then explain what changed in the input and what stayed stable in the decision rule.

What this does not prove

This lesson does not claim certification, production guarantees, or coverage of every implementation. Its conclusion is valid only within the scenario boundary, dated sources, and recorded observations.

Self-check

• [ ] Did I separate responsibilities from framework or tool names?
• [ ] Did I state at least one failure probe and its predicted observable?
• [ ] Are fact, inference, and design choice visibly separated?
• [ ] Did I record non-claims and missing evidence?
• [ ] Did I complete transfer in a changed context without a prepared answer?

Sources and freshness boundary

Sources were reviewed for the frozen Bible as of 2026-09-19. A review_due date triggers a versioned requalification; it does not authorize silent in-place edits.

• S-WHATWG-SSE — WHATWG HTML defines EventSource, text/event-stream framing and Last-Event-ID behavior. (https://html.spec.whatwg.org/dev/server-sent-events.html; review: 2026-10-17)
• S-MDN-SSE — MDN documents data/id/retry fields and browser reconnection behavior as implementation guidance. (https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events; review: 2026-10-17)