5 ms·

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

by qubyte 11y ago

supermatt 11y ago
Sadly these shims require a per-client queue to ensure message delivery, as events will otherwise be lost during reconnections.
- qubyte 11y ago
  I'm not sure I'm following you. How does this differ from native EventSource?
  - supermatt 11y ago
    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!
    - qubyte 11y ago
      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).
  - deleted 11y ago
    [deleted]
- tehbeard 11y ago
  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.
fweespeech 11y ago
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 http://caniuse.com/#feat=websockets
- ipmb 11y ago
  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 https://speakerdeck.com/3rdeden/websuckets tl;dr websockets can fail in strange ways on mobile and when passed through proxies and corporate firewalls

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

by qubyte 11y ago

SSE is easy to shim! We use: https://github.com/Yaffle/EventSource/ 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.

qubyte 11y ago
I'm not sure I'm following you. How does this differ from native EventSource?
- supermatt 11y ago
  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!
  - qubyte 11y ago
    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).
- deleted 11y ago
  [deleted]
tehbeard 11y ago
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.

fweespeech 11y ago

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 http://caniuse.com/#feat=websockets

ipmb 11y ago
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 https://speakerdeck.com/3rdeden/websuckets tl;dr websockets can fail in strange ways on mobile and when passed through proxies and corporate firewalls