Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Server-Sent Events: an alternative to WebSockets

germano.dev

Post reply on HN
Print view View original

161–170 of 266 posts

Re: Server-Sent Events: an alternative to WebSockets

#161

Post by mmcclimon »

coder543 wrote: post #147
ok_dad wrote: post #127

Earlier quoted context omitted.

> the only thing I don't like about them is that Firefox dev tools make them totally impossible to debug You can't say that and not say more about it, haha. Please expand on this? Also, I'm a Fastmail customer and appreciate the nimble UI, thanks!

I think their information could be outdated. Since Firefox 82, you can supposedly inspect the content of SSE streams: https://developer.mozilla.org/en-US/docs/Tools/Network_Monit... Before that... yeah, the Firefox dev tools were not very helpful for SSE.

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!

Re: Server-Sent Events: an alternative to WebSockets

#163

Post by coder543 »

mmcclimon wrote: post #161
coder543 wrote: post #147

Earlier quoted context omitted.

I think their information could be outdated. Since Firefox 82, you can supposedly inspect the content of SSE streams: https://developer.mozilla.org/en-US/docs/Tools/Network_Monit... Before that... yeah, the Firefox dev tools were not very helpful for SSE.

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.

Re: Server-Sent Events: an alternative to WebSockets

#164

Post by 0xbkt »

jessaustin wrote: post #152
laerus wrote: post #141

With WebTransport around the corner I don't think is worth the time investing in learning a, what seems to me, obsolete technology. I can understand it for already big projects working with SSE that don't want to pay the cost of upgrading/changing but for anything new I cannot be bothered since Websockets work good enough for my use cases. What worries me though is the trend of dismissal of newer technologies as bein…

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.

Re: Server-Sent Events: an alternative to WebSockets

#165

Post by dabeeeenster »

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!

Re: Server-Sent Events: an alternative to WebSockets

#166

Post by coder543 »

szastamasta wrote: post #146
coder543 wrote: post #99

Earlier quoted context omitted.

> If you’re using tokens for auth and don’t want to use session cookies That sounds like a self-inflicted problem. Even if you’re using tokens, why not store them in a session cookie marked with SameSite=strict, httpOnly, and secure? Seems like it would make everything simpler, unless you’re trying to build some kind of cross-site widget, I guess.

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.

Re: Server-Sent Events: an alternative to WebSockets

#167

Post by Spivak »

smw wrote: post #114
bullen wrote: post #107

Earlier quoted context omitted.

We already discussed this in an earlier thread, and however bad this looks it's better than my own license. Here it's clear, you can either use the code without money involved and then you have MIT (+ show logo and some example code is still mine). If you want money then you have to share some of it.

I respect your right to license you product however you want, but please don't call that open source.

Requiring attribution doesn’t make something not open source. At best this means that the example code isn’t open source.

Re: Server-Sent Events: an alternative to WebSockets

#168

Post by jessaustin »

tgv wrote: post #94

But SSE is a oneway street, isn’t it? The client gets one chance to send days, and that’s it? Or is there some way around it?

Clients can always send normal http messages to the server. Probably not ideal for "bi-directional" traffic, but it's an option in a pinch.

Re: Server-Sent Events: an alternative to WebSockets

#169

Post by dkersten »

bullen wrote: post #107
Aeolun wrote: post #101

Earlier quoted context omitted.

> MIT but [bunch of stuff] Not MIT then. The beauty of MIT is that there is no stuff.

We already discussed this in an earlier thread, and however bad this looks it's better than my own license. Here it's clear, you can either use the code without money involved and then you have MIT (+ show logo and some example code is still mine). If you want money then you have to share some of it.

While I get and support the intent, I don't like this usage of the name of the MIT license. I personally like the license because it tells me at a glance that I can use it for any purpose, commercial or otherwise, as long as the copyright and license is included and that there is no warranty. That's it, no complications, no other demands, no "if it makes X money or not", just I include the copyright and license terms and that's it, I can use the software whichever way I like.

Your license is not that. You have extra conditions that add complexity. I can no longer go "oh like MIT" and immediately use it for any purpose, because you require extras especially if I were to make money. That seems completely against the spirit of the simplicity of the MIT license which says you can do whatever you like, commercial or otherwise, as long as the copyright and license are included.

I think you should make your own license that includes the text of the MIT license, except removing the irrelevant parts (ie the commercial aspects include a caveat about requiring payment). You can still have a separate line of text explaining that the license is like the MIT license but with XYZ changes (basically the text you have now). But the license is not the MIT license and you should therefore have a separate license text that spells it out exactly. Not "its this, except scratch half of it because these additional terms override a good chunk of it".

Re: Server-Sent Events: an alternative to WebSockets

#170

Post by dlsa »

bullen wrote: post #16

I made the backend for this MMO on SSE over HTTP/1.1: https://store.steampowered.com/app/486310/Meadow/ We have had a total of 350.000 players over 6 years and the backend out-scales all other multiplayer servers that exist and it's open source: https://github.com/tinspin/fuse You don't need HTTP/2 to make SSE work well. Actually the HTTP/2 TCP head-of-line issue and all the workarounds for that probably make it hard…

Couldn't find a license file in the root folder of that github. I found a license in a cpp file buried in the sec folder. You should consider putting the licensing for this kind of project in a straightforward and locatable place.
Post reply on HN