whois “Tasos Bitsios”

• Long time listener, first time speaker

Server-Sent Events (SSE)

• Streaming protocol

• Essentially a streaming GET

  • Server writes more data as it becomes available

Polling vs SSE

Like polling but better

Best suited for UTF-8 updates

Especially for multiple update channels

Like WebSockets but -

• Not really

• Unidirectional & UTF-8

Use cases: Notifications

Use cases: Real-time ticker data

Use cases: Async job progress

Use cases: Kadena

Can I use?

Yes (96.11%)

caniuse.com/eventsource

What is this new thing?

Largely overlooked: Google Trends

Largely overlooked: StackOverflow

Largely overlooked: why?

Contemporary to Web sockets, HTML5, <video>, Web workers, Web storage

Narrow use case

Playground

• Repo with example SSE server in express
• Client in React
• Explore various scenarios
• github.com/takadenoshi/sse-presentation/

Minimum Viable SSE response

The simplest server-sent event stream specifies just data events.

> GET /stream/hello HTTP/1.1

< HTTP/1.1 200 OK
< Content-Type: text/event-stream

< data: Hello\n\n

< data: ReactLive are you there?\n\n

Simple EventSource consumer

Client-side: SSE consumer API is EventSource

let i=0;

const source = new EventSource("http://localhost:3001/stream/simple");

// "message" event emitted for each "data" event received
source.addEventListener("message", event => console.log(++i, event.data), false);

// or .onmessage = (...) if that is your jam

< HTTP/1.1 200 OK
< Content-Type: text/event-stream

< data: Hello\n\n

< data: ReactLive are you there?\n\n

1 Hello

2 ReactLive are you there?

Named Events

You can “namespace” your events using the event field with any custom name:

< event: goal
< data: "ARS-LIV 1-1 45"\n\n

< event: spectator-chat
< data: "Did you see that ludicrous display just now"\n\n

Interactive part - scan me!

Scan the QR to interact with this presentation directly

Named Events: Live Demo

In the live reactions demo, we stream two types of things:

• clients event: number of clients
• data event: array of emoji enum values (1-8)

< event: clients
< data: 10

< data: [1,2,3,4]

Reconnection (1)

EventSource will reconnect if the connection is interrupted.

Default reconnection timeout ~ 3-5 s.

Reconnection (2) - Custom timeouts

The reconnection timeout can be customized.

Emit a retry: field in any of the events:

< retry: 2500
< data: Hello!\n\n

• Value is in milliseconds
• Timeouts are linear

^{Playground: “Retry-flaky” scenario}

Reconnection (3) - Last-Event-ID

Events can include an id field with any UTF-8 string as value

Connection interrupted? Sets reconnection header Last-Event-ID: x

< id: data-0
< retry: 5000
< data: Data Zero event\n

💔 Disconnects ➡️ 5 seconds later

> GET /stream/notifications
> Last-Event-ID: data-0

Comments

Any lines starting with : (colon)

< :TODO emit some events in the near future

These are ignored on the client-side

Full SSE response

> GET /stream/hello HTTP/1.1

< HTTP/1.1 200 OK
< Content-Type: text/event-stream

< retry: 2000
< id: 0
< data: {"message":"Hello"}\n\n

< :I am a comment

< id: 1
< event: status
< data: {"warn":"Service degraded"}\n\n

EventSource: named events

You can subscribe to custom events with .addEventListener:

const source = new EventSource('/stream/hello');

// [name]: triggers for custom named event, here: "status"
source.addEventListener(
  "status",
  ({ data }) => console.log("custom event: status", JSON.parse(data)),
  false,
);

EventSource: connection events

Subscribe to open and error for connection management:

// on connection established
source.addEventListener(
  "open",
  (event) => { console.log("Connection opened"); },
  false
);

// on error or disconnection
source.addEventListener(
  "error",
  (event) => { console.log("Connection error"); },
  false
);

The EventSource Interface

• constructor(url, { withCredentials })
  • withCredentials: boolean use CORS credentials (default: false)
• Events: open | error | message | <custom-name>
• close()
• readyState: State intent enum: CONNECTING (0) | OPEN (1) | CLOSED(2)
  • CONNECTING: also “waiting to reconnect”
  • CLOSED: will not attempt to reconnect

In React

• Manage eventSource, which is stateful
• Could use useEffect or a custom hook

  useEffect(() => {
    const eventSource = new EventSource(` http://localhost:3001/stream/${endpoint}` );

    // connection mgmt
    eventSource.addEventListener('open', () => console.log("Got open"));
    eventSource.addEventListener('error', () => console.log("Got error"));

    // data callbacks
    eventSource.addEventListener('message', () => console.log("Got message"));
    eventSource.addEventListener('custom', () => console.log("Got custom"));

    // destroy when unloaded
    return () => eventSource.close();
  }, []);

You should definitely use it

Error event is a bit useless

• Single bit of information: “error”

• callback signature is (event: Event) => void

  • event.target is instanceof EventSource
  • no reason / message / code

Implementation Considerations: HTTP/1.1

HTTP/1.1 connections quota

Max number of connections: 6

Per-hostname quota

Browser-wide enforcement (shared by all tabs)

Implementation Considerations: HTTP/1.1

Possible Solutions

• Prefer HTTP/2 where available (can-i-use 96% yes)
  • max number of simultaneous HTTP streams is negotiated (defaults to 100)

Implementation Considerations: Reconnecting

Different Browser Implementations

When a network error is encountered:

• Firefox: stops retrying (standard compliant)
• Chrome: keeps retrying (actually helpful)

Implementation Considerations: Computer says no

A server can signal “do not reconnect”:

• with a Content-Type header other than text/event-stream
• with a status code other than:
  • 200
  • 3xx redirect to a 200

^{Playground: “Not SSE” scenario}

Implementation Considerations: Reconnecting

Important payload?

Consider handling reconnections explicitly

• onerror -> evtSrc.close(); setTimeout() ...
• Ensure uniform behavior

Implementation Considerations: Proxies (1)

Proxies can kill

Some proxies dislike idle connections & will kill them quickly. Fix(es):

1/ Comment (not client-aware)

You can emit a comment

< :)

Good enough to keep connection alive.

EventSource won’t emit any event.

Implementation Considerations: Proxies (2)

Proxies can kill

Some proxies dislike idle connections & will kill them quickly. Fix(es):

2/ Heartbeat event (client-aware)

Emit a custom event every ~15 seconds:

< event: heartbeat
< data: ""

(data field must be present)

Use it to detect stale connections: “expect heartbeats every N seconds, otherwise reconnect”

Implementation Considerations: 🔥 🦊 💁 🤖

Firefox Service Workers 💔 EventSource

Firefox has yet to implement support for EventSource in its Service Worker context.

Future people can track the present validity of this statement here.

✅ But you can use it in a SharedWorker

whois “Kadena”

• Scalabe PoW Blockchain: Chainweb

• 20x braided chains

Chainweb use case

Blockchain stuff usually comes with lots of polling. E.g. determining finality

Thank you