Hacker News Reader

Comment by qubyte | Hacker News Reader

SSE is easy to shim! We use: https://github.com/Yaffle/EventSource/

Sadly these shims require a per-client queue to ensure message delivery, as events will otherwise be lost during reconnections.

Really you should have a queue anyway to account for those on less reliable connections (mobile, satellite, comcast)

EventSource natively supports this via the "Last-Event-ID" header (and can also be used by a shim to ensure it gets messages it missed). And in the case of a room style app you probably already have a room history that can be used to provide this data.

I'm not sure I'm following you. How does this differ from native EventSource?

EventSource sends all events over a single connection which it keeps open indefinitely. This shim receives a single event and then reconnects. In that window there is a period where there will be no connection to send events over, so they will be lost without a queue.

Edit: actually this looks to be a lot more sophisticated than the other shims i havr looked at and does indeed behave more like eventsource. Good job!

Ah, you're suggesting that the shims use long-polling. I don't think that's the case though. If I understand the library correctly, it really is keeping a connection open, so it's really very similar to the way EventSource works.

Addition: Verified. It doesn't disconnect between events (not long-polling).

That looks like a very high quality shim, so that is good.

However, why would I want to use a shim over websockets?

http://caniuse.com/#feat=websockets

I'm not sure how much of this still holds true, but here's a few reasons you might want to stick to HTTP: https://speakerdeck.com/3rdeden/websuckets

tl;dr websockets can fail in strange ways on mobile and when passed through proxies and corporate firewalls

Reply on news.ycombinator.com