Server-Sent Events: an alternative to WebSockets • Hacker News Board

Re: Server-Sent Events: an alternative to WebSockets

#171

Post by jessaustin » Sat, Feb 12, 2022, 9:27 PM UTC

0xbkt wrote: post #164

jessaustin wrote: post #152

Earlier quoted context omitted.

Around the corner? There seems to be nothing about this in any browser. [0] That would put this what, five years out before it could be used in straightforward fashion? Please be practical. [0] https://caniuse.com/?search=webtransport

See https://github.com/Fyrd/caniuse/issues/5707 and https://chromestatus.com/feature/4854144902889472#consensus .

Thanks for pointing that out. I suppose caniuse missing out on the first experimental version of the first browser to support this isn't terribly misleading. Maybe when they get the basics of the API figured out we can start deprecating other things...

Re: Server-Sent Events: an alternative to WebSockets

#172

Post by szastamasta » Sat, Feb 12, 2022, 9:29 PM UTC

coder543 wrote: post #166

szastamasta wrote: post #146

Earlier quoted context omitted.

I need to work with more than 1 backend :)

This is such an opaque response, I don't know what else could be said. If you're sending the same token to multiple websites, something feels very wrong with that situation. If it's all the same website, you can have multiple backends "mounted" on different paths, and that won't cause any problems with a SameSite cookie.

Then you need a single point of failure that is handling session validation. Without it part of your app might work even without your sessions storage.

Re: Server-Sent Events: an alternative to WebSockets

#173

Post by coder543 » Sat, Feb 12, 2022, 9:40 PM UTC

szastamasta wrote: post #172

coder543 wrote: post #166

Earlier quoted context omitted.

This is such an opaque response, I don't know what else could be said. If you're sending the same token to multiple websites, something feels very wrong with that situation. If it's all the same website, you can have multiple backends "mounted" on different paths, and that won't cause any problems with a SameSite cookie.

Then you need a single point of failure that is handling session validation. Without it part of your app might work even without your sessions storage.

You can store a JWT in a session cookie. You don’t need a SPoF for session validation, if that’s not what you want.

Re: Server-Sent Events: an alternative to WebSockets

#174

Post by ec109685 » Sat, Feb 12, 2022, 9:42 PM UTC

dabeeeenster wrote: post #165

mythz wrote: post #42

We use SSE for our APIs Server Events feature https://docs.servicestack.net/server-events with C#, JS/TypeScript and Java high-level clients. It's a beautifully simple & elegant lightweight push events option that works over standard HTTP, the main gotcha for maintaining long-lived connections is that server/clients should implement their own heartbeat to be able to detect & auto reconnect failed connections which wa…

"the main gotcha for maintaining long-lived connections is that server/clients should implement their own heartbeat to be able to detect & auto reconnect failed connections" That sounds like a total nightmare!

Definitely needed. That would be true for all long lived connection protocols in order to detect connection interruptions in a timely fashion.

Re: Server-Sent Events: an alternative to WebSockets

#175

Post by 88913527 » Sat, Feb 12, 2022, 9:45 PM UTC

patrickthebold wrote: post #150

88913527 wrote: post #97

Earlier quoted context omitted.

HTTP headers must be written before the body; so once you start writing the body, you can't switch back to writing headers. Server-sent events appears to me to just be chunked transfer encoding [0], with the data structured in a particular way (at least from the perspective of the server) in this reference implementation (tl,dr it's a stream): https://gist.github.com/jareware/aae9748a1873ef8a91e5#file-s... [0]: https…

Maybe I misunderstood your claim, but there is: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Tr... Which seems to be what you need to send 'headers' after a chunked response.

You understood correctly; I was mis-informed. Today I learned about the "Trailer" header. I'm curious how HTTP clients handle that. A client like window.fetch will resolve with a headers object-- does it include the trailers or not? I'd have to test it out.

Re: Server-Sent Events: an alternative to WebSockets

#176

Post by mmcclimon » Sat, Feb 12, 2022, 9:57 PM UTC

coder543 wrote: post #163

mmcclimon wrote: post #161

Earlier quoted context omitted.

Hmm! You're right that I hadn't looked it a while, so I checked before making the comment above. I'm still seeing the same thing I always have, which is "No response data available for this request". Possibly something is slightly wrong somewhere (though Chrome dev tools seem fine on the same), but you've given me something to look into, thanks!

That is interesting. I just tested it myself, and at least for my setup (Firefox on Mac on ARM), the events only showed up in the dev tools if the server closed the SSE connection... so, maybe Firefox still hasn't fully fixed this problem.

Yeah, that seems to be the case (confirmed with their little example at https://github.com/mdn/dom-examples/tree/master/server-sent-...). Once the connection is closed you can see things, but that's not particularly useful for debugging!

Re: Server-Sent Events: an alternative to WebSockets

#177

Post by dnr » Sat, Feb 12, 2022, 9:58 PM UTC

mmcclimon wrote: post #61

SSEs are one of the standard push mechanisms in JMAP [1], and they're part of what make the Fastmail UI so fast. They're straightforward to implement, for both server and client, and the only thing I don't like about them is that Firefox dev tools make them totally impossible to debug. 1. https://jmap.io/spec-core.html#event-source

The Fastmail UI is indeed snappy, except when it suddenly decides it has to reload the page, which seems to be multiple times a day these days (and always when I need to search for a specific email). Can you make it do what one of my other favorite apps does: when there's a new version available, make a small pop up with a reload button, but don't force a reload (until maybe weeks later)?

Re: Server-Sent Events: an alternative to WebSockets

#178

Post by ponytech » Sat, Feb 12, 2022, 9:59 PM UTC

One problem I had with WebSockets is you can not set custom HTTP headers when opening the connection. I wanted to implement a JWT based authentication in my backend and had to pass the token either as a query parameter or in a cookie.

Anyone knows the rationale behind this limitation?

Re: Server-Sent Events: an alternative to WebSockets

#179

Post by hishamp » Sat, Feb 12, 2022, 10:05 PM UTC

We moved away from WebSockets to SSE, realised it wasn't makings thing any better. In fact, it made things worse, so we switched back to WebSockets again and worked on scaling WebSockets. SSE will work much better for other cases, just didn't work out for our case.

First reason was that it was an array of connections you loop through to broadcast some data. We had around 2000 active connections and needed a less than 1000ms latency, with WebSocket, even though we faced connections drops, client received data on time. But in SSE, it took many seconds to reach some clients, since the data was time critical, WebSocket seemed much easier to scale for our purposes. Another issue was that SSE is like an idea you get done with HTTP APIs, so it doesn't have much support around it like WS. Things like rooms, clientIds etc needed to be managed manually, which was also a quite big task by itself. And a few other minor reasons too combined made us switch back to WS.

I think SSE will suit much better for connections where bulk broadcast is less, like in shared docs editing, showing stuff like "1234 users is watching this product" etc. And keep in mind that all this is coming from a mediocre full stack developer with 3 YOE only, so take it with a grain of salt.

Re: Server-Sent Events: an alternative to WebSockets

#180

Post by DaiPlusPlus » Sat, Feb 12, 2022, 10:30 PM UTC

hishamp wrote: post #179

We moved away from WebSockets to SSE, realised it wasn't makings thing any better. In fact, it made things worse, so we switched back to WebSockets again and worked on scaling WebSockets. SSE will work much better for other cases, just didn't work out for our case. First reason was that it was an array of connections you loop through to broadcast some data. We had around 2000 active connections and needed a less than…

Your write-up sounds like your issues with SSE stemmed from the framework/platform/server-stack you're using rather than of any problems inherent in SSE.

I haven't observed any latency or scaling issues with SSE - on the contrary: in my ASP.NET Core projects, running behind IIS (with QUIC enabled), I get better scaling and throughput with SSE compared to raw WebSockets (and still-better when compared to SignalR), though latency is already minimal so I don't think that can be improved upon.

That said, I do prefer using the existing pre-built SignalR libraries (both server-side and client-side: browser and native executables) because the library's design takes away all the drudgery.