← Back to context

Comment by lexicality

3 years ago

Feels like a bit silly not to have made this compatible with SSE since all the mechanisms for acessing that are built into browsers these days.

https://developer.mozilla.org/en-US/docs/Web/API/Server-sent... https://html.spec.whatwg.org/multipage/server-sent-events.ht...

50 comments

lexicality

Reply
rendall  3 years ago

> "Feels like a bit silly not to have made this compatible with SSE ..."

The feedback is great, and valid. I wish it could have been expressed less dismissively though.

  • sam_lowry_  3 years ago

    Depending on the culture you are living in, this can be perceived as either dismissive or respectful.

    I was curious enough to browse through the comments of @lexicality to conclude that he is European, so there is a chance that you were considered capable of receiving a direct feedback.

    That is, by giving direct feedback, @lexicality showed you respect.

    • rendall  3 years ago

      The feedback isn't to me.

      Also, I live in northern Europe. Generally feedback is direct, but respectful. Calling something silly is usually (but not always) out of bounds. European-style feedback might be: "I'm surprised you did not use X because it perfectly matches your use case."

      Or "Great feedback but I wish it could have been expressed less dismissively"

      15 replies →

    • glenstein  3 years ago

      I don't agree that this instance is among the kind that can "be perceived as respectful" - I think we can make space to acknowledge that that is a thing, and that nevertheless this is not an instance of respectfully direct communication. So that's a red herring.

      Moreover I don't see that "being European" has anything to do with anything, and classifying someone as either being "capable of" or not "capable of" receiving direct feedback, far from respectful, is an instance of insulting with plausible deniability, which is perhaps the most practiced art form of internet comment sections.

    • politelemon  3 years ago

      Calling something silly is not direct, nor respectful.

      Perhaps your view of communication with Europeans is influenced by other factors that's led you to this conclusion? (or to put it respectfully, silly)

      4 replies →

  • michael_j_ward  3 years ago

    Do you find it easy to find great, honest, and valid feedback on the internet?

    How much of the supply of great, honest, and valid feedback would you sacrifice in order to make the supply that remains use "less dismissive"[0] language like "a bit silly"?

    [0] Less dismissive in quotes because I do not find that language dismissive in the slightest

  • rendall  3 years ago

    Let's chalk it up to cultural difference! Some commenters think "silly" is fine (Ireland, UK, US - although I'm from the US and I disagree, but let's grant it). Some think it's not.

    Let's assume that "silly" was meant kindly and not dismissively!

r3trohack3r  3 years ago

Had never heard of SSE before. Followed the link and found this warning:

> Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, which means that you can open 6 SSE connections across all of the tabs to www.example1.com and another 6 SSE connections to www.example2.com (per Stackoverflow). When using HTTP/2, the maximum number of simultaneous HTTP streams is negotiated between the server and the client (defaults to 100).

This is the first time I’ve heard of per-domain connection limits. Seems… not great? Doesn’t this turn into a client side DoS? User opens 6+1 tabs and now the browser has exhausted all HTTP connections to your domain serving SSE connections?

I’ve used long polling before, I don’t understand how I’ve never observed the connection limit of 6…

aiobe  3 years ago

Hi! I am the author of http-feeds.org. Thank you for your feedback.

For this spec I aimed to keep it as simple as possible. And plain polling-based JSON Endpoints are the most simple and robust endpoints IMHO.

If you need, you could implement an SSE representation on the server endpoint by prober content negotiation.

The main reason, why I dropped SSE it the lack of proper back pressure, i.e. what happens when a consumes slower than the server produces messages. Plus, it is quite hard to debug SSE connections, e. g. no support by Postman and other dev tools. And long lasting HTTP connections are still a problem in todays infrastructure. E. g. there is currently no support for SSE endpoints in Digital Ocean App Platform, and I am not sure about them in Google Cloud Run.

Overall, plain GET endpoints felt much simpler.

  • lexicality  3 years ago

    I'm not entirely sure what you mean by this. SSEs are just normal GET requests with a custom header and some formal logic around retries. I've even implemented them manually with PHP using the `retry` command to mean I don't need to have the connection open for longer than a normal pageload.

    > The main reason, why I dropped SSE it the lack of proper back pressure, i.e. what happens when a consumes slower than the server produces messages.

    Could you point me to where the spec handles this please? As far as I can tell it has the same problem of the server needing to buffer events until the client next connects

  • toomim  3 years ago

    Thank you for writing this great spec up for others to use!

    I think totally right that back-pressure and plain GETs are an important use-case to support, and am really happy to see a beautiful spec written up to articulate concretely how to support them.

    It is also great to be able to switch amongst these methods of subscription, for instance, if your server can keep a persistent connection open, it's nice to be able to get realtime updates over a single channel, but to still be able to fall back to polling or long-polling if you can't. And if you switch between a polling and a subscription, it's nice if you don't have to change the entire protocol — but can just change the subscription method.

    There's a growing effort to integrate all our various subscription-over-http protocols into an IETF HTTP standard, that we can use for all these use-cases: https://lists.w3.org/Archives/Public/ietf-http-wg/2022JanMar...

    Maybe you'd be interested in incorporating your experience, use-cases, and design decisions into that effort? We have been talking about starting at this November's IETF. [1]

    For instance, you can do polling over the Braid protocol [2] with a sequence of GETs, where you specify the version you are coming from in the Parents: header:

        GET /foo
    Parents: "1"

    GET /foo
    Parents: "2"

    GET /foo
    Parents: "3"

    Each response would include the next version.

    And you can get back-pressure over Braid by disconnecting a subscription when your client gets overwhelmed, and then reconnecting again later on with a new Parents: header:

        GET /foo
    Subscribe: true
    Parents: "3"

    ..25 of updates flow back to the client..

    **client disconnects**

    Now the client can reconnect whenever it's ready for new data:

        GET /foo
    Subscribe: true
    Parents: "28"

    Or if it wants to re-fetch an old version, it can simply ask for it via the version ID it got:

        GET /foo
    Version: "14"

    And if the source for these updates is a git repository, we could use a SHA hash for the version instead of an integer:

        GET /foo
    Version: "eac8eb8cb2f21c5e79c305c738aa8a8171391b36"
    Parents: "8f8bfc8ea356d929135d5c3f8cb891031d1539bd"

    There's a magical universality to the basic concepts at play here!

    [1] https://www.ietf.org/how/meetings/115/

    [2] https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-b...

technicolorwhat  3 years ago

Yeah, we're also pushing for SSE for this kind of things.

  • mromanuk  3 years ago

    I had previously used SSE in a project and had no idea it existed or that it was widely supported by most browsers. It's a beautiful and straightforward technology, but it doesn't seem to be as widely used as it should be, and more tooling is required. Also more tooling is required.

    • masklinn  3 years ago

      The really huge issue with SSE, and the reason why it’s historically been dismissed, is that it us subject to (and counts towards) the HTTP 1.1 domain connection limit.

      Sadly that makes it a bit of a pain in the ass to manage for sites served as (/ compatible with) http 1.1.

    • jslakro  3 years ago

      I know SSE works on scenarios with few or no state updates, like in dashboard UI's. What about other cases where they deal with input data? like in a chat/game

      1 reply →

  • horstmeyer  3 years ago

    Does SSE work reliably in mobile browsers nowadays? A few years back when I tried, it was working OK in Chrome for Android but mobile browser support didn't seem complete.

    • gunapologist99  3 years ago

      Sadly, there are very few mobile browsers that aren't Chrome or Safari. In fact, Safari/Webkit is the only mobile browser engine available on IOS at all -- all other browsers are just chrome (pun intended) around IOS webkit.

      To your point, https://caniuse.com/eventsource

      Also there are polyfills for very old browsers like IE.

  • lexicality  3 years ago

    Having a standard for what events look like is a decent idea as people generally just make some random thing up without thinking too hard and having a standard is generally helpful - but making your own polling system etc when there's already a battle tested one available seems like wasted effort and a bit counterproductive