Server-Sent Events: The simplest realtime browser spec

https://segment.io/blog/2014-04-03-server-sent-events-the-simplest-realtime-browser-spec/

by ianstormtaylor • 12 years ago

64 31 12 years ago

ukd1• 12 years ago

Server-Sent Events rock; love what these guys have done with the live debugger - it's been -massive- help debugging our events (which go through segment)!

rdtsc• 12 years ago

It is a really nice things, except IE doesn't implement them so yeah, kind of useless.

It would be nice to say screw IE users but not everyone can do that.

dayjah• 12 years ago

+1, SSE is great. We (Twitch) use it between systems in a few key cases since it is really easy to make a client for it if you find yourself in a language that doesn't already have it baked into their HTTP client offering.

When it comes to browsers we've still not found a solution that is as solid as Flash sockets; though that could also be a bit of a hangover for us given our reliance on Flash and the subsequent tooling that we have around it.

byroot• 12 years ago

They are very easy to shim with polling though.

eknkc• 12 years ago

Here's a polyfill: https://github.com/Yaffle/EventSource/

2 issues; Last-Event-ID is not a header, but a querystring param. Needs 2kb of padding from server before any data.

Looks pretty usable.

csears• 12 years ago

SSE is listed as "under construction" on the IE roadmap: http://status.modern.ie/serversenteventseventsource

skybrian• 12 years ago

"Under consideration" actually.

imthatguyama• 12 years ago

MS tried to look all hip and cool with IE10/11 and SSE didn't have much buzz around it so it wasn't implemented.

dochtman• 12 years ago

I particularly love how you can get Server-Sent Events out of a CouchDB database changes feed. This is such a powerful and extremely easy way of sending real-time updates to a web client.

conorgil1453• 12 years ago

That sounds really neat. Do you have any links to resources or blog posts explaining how you hooked the two together? Does CouchDB support that out of the box?

vertex-four• 12 years ago

Just did a bit of research, and while it doesn't seem to be documented in the guide, simply appending ?feed=eventsource to the changes URL should get you the event source URL in CouchDB >1.3.0.

puppetmaster33• 12 years ago

Honestly, much easier and more reliable via PubNub.com or such.

conorgil1453• 12 years ago

I have not used either service. What makes PubNub.com easier and/or more reliable?

puppetmaster33• 12 years ago

Because they fail over several different protocols transparent to you.

And much more effective than DIY. API's are much nicer than old school.

woah• 12 years ago

Sometimes it's nice to look at what's coming down the pipeline and will be standard soon. When you spend time learning compatibility workarounds, that knowledge becomes more dated by the minute.

But for production, yea.

eranation• 12 years ago

Nice post, and interesting timing, just published a post on how to do SSE with Java: http://eranmedan.com/server-side-events-sse-in-java and... I must admit the Node.js version is clearly more concise and elegant :) but still this is one of the simplest ways to do server side "push", if only IE supported it... though you can always use a polyfill: https://github.com/Yaffle/EventSource/

(though that polifill didn't work for me for that example, but I didn't spend much time trying to figure out why)

djKianoosh• 12 years ago

Nice. Do you recommend any specific reading for wiring up some backend services like a pub/sub message queue into something like the SSE example you have?

jkarneges3• 12 years ago

Yeah I love how dirt simple SSE is. WebSockets tend to be the go-to choice for realtime push, but many applications don't really need a bidirectional socket. SSE for server->client and XHR for client->server interactions is good enough for typical REST apps.

Also, (plug alert) SSE is pretty easy to throw together using https://fanout.io/ and its HTTP streaming data transport, if you want to save yourself from having to set up any new server stuff.

conorgil1453• 12 years ago

It is not immediately obvious to me what fanout.io does from your homepage. Could you add an example?

Clients register to listen with the fanout.io CDN, then my app pushes something to the CDN, and fanout.io handles pushing it to all of my end clients?

Can I determine which subset of users receive the message, or is it "all or nothing"? Are clients able to listen on a specific topic/name?

I'd love to get more info, but I didn't see any higher level explanation and don't have time to dive into docs right now.

X-Cubed• 12 years ago

Surely chunked encoding would work more reliably for sending chunks of data from the server? http://en.wikipedia.org/wiki/Chunked_transfer_encoding

jkarneges3• 12 years ago

Any SSE server almost certainly uses chunked encoding.

Though technically a non-chunked Content-Length-less HTTP/1.0-style response should work too.

chrismorgan• 12 years ago

It's one of the sad facts of life that when you design a popular protocol like HTTP/1.1 so that it can do something, but don't actually do anything with it, many implementers drop it.

Many HTTP servers will not allow you to specify precisely where you break chunks; I would expect that the significant majority of slightly higher level interfaces will not allow you to do that, rather handling buffering themselves.

Many HTTP clients will not allow you to read chunks precisely.

And as for the "event" paramter—well, such things are taken care of in RFC 2616 with chunk extensions; it would end up being

    <length of data in hex> ";event=" event-name CRLF data CRLF

e.g. you would replace the following chunk-encoded data (the first and last lines are artefacts of the chunked transfer encoding):

    1d␍␊
    event: poke␍␊
    data: "hey!"␍␊
    ␍␊
    ␍␊

with the following:

    6;event=poke␍␊
    "hey!"␍␊
    ␍␊

Unfortunately, chunk extensions have never really been used, so I dare say they assessed that technique and decided that it was simply going to require too much work. And so we're left with a new protocol on top of HTTP reimplementing precisely what HTTP already did, but which people forgot about, possibly for performance reasons.

klibertp• 12 years ago

Isn't this basically what we did some 10 years ago with a hidden, slowly loading iframe? It was widely known and used then, I suppose the technique became less important and forgotten with AJAX arrival and is now being rediscovered.

The only problem with this is c10k - you have to have something writing to the socket and this "something" was basically a process in most cases. It's a great fit for async things like Node or Twisted/Tornado, though. And for Erlang.

skue• 12 years ago

Yes, the umbrella term for this HTTP server push is Comet[1], and it's been around in various forms for years. But standardizing this in the form of server-sent events is a very Good Thing, especially with support baked into modern browsers.

Also, unlike WebSockets it's also easy to add SSE support for mobile clients. I've implemented a SSE client class in just over 100 lines of Java, and it's similarly easy to do this with NSURLConnection/NSURLSession on iOS. The W3 standard provides an implementation section that reads like pseudocode.[2]

[1] https://en.wikipedia.org/wiki/Comet_%28programming%29

[2] http://dev.w3.org/html5/eventsource/#event-stream-interpreta...

pornel• 12 years ago

On the HTTP level it's quite similar to slow-loading iframes (although with less overhead on the wire), but the interface and usability are better.

The browser will try hard to keep the connection always on for you (unless instructed otherwise). You don't have to implement your own logic for offline/online detection, exponential backoff, etc. Thanks to id:/Last-Event-Id header the server can make error recovery transparent to the client.

You do need node/tornado/etc to take full advantage of it, but if all you have is PHP or such, then you can still make it real-time-ish. Because SSE automatically reconnects you can have any behavior ranging from a single persistent TCP/IP connection, through Comet, to regular polling. You control this with the `retry:` line and by (not) closing connection on the server (e.g. keep persistent connection when load on the server is low, set high `retry:` and close the connection when the load is high).

rahilsondhi• 12 years ago

FYI not compatible with any version of IE. Source: http://caniuse.com/eventsource

elwell• 12 years ago

That was mentioned in the article, and some polyfills were given.

robmueller• 12 years ago

SSE is great. We wrote about it in quite a bit of detail a while back.

http://blog.fastmail.fm/2012/01/09/building-the-new-ajax-mai...

There's a couple of annoying caveats

1. The "retry" nature of the connection isn't quite as reliable as suggested. See the blog post above for more details

2. NAT timeouts. Make sure you have some sort of "ping" either at application or TCP level.

http://blog.fastmail.fm/2013/05/28/push-events-nat-tcp-conne... http://blog.fastmail.fm/2011/06/28/http-keep-alive-connectio...

3. Each SSE connection is regarded as a regular site connection. So if people open up 6 tabs to your site, you might suddenly find your site is unresponsive to users because every available connection is used by an SSE connection. You might need to implement some inter-tab communication system instead.

http://blog.fastmail.fm/2012/11/26/inter-tab-communication-u...

Server-Sent Events: The simplest realtime browser spec

Related Stories