141–150 of 266 posts
What worries me though is the trend of dismissal of newer technologies as being useless or bad and the resistance to change.
Earlier quoted context omitted.
Absolutely not, HTTP/1.1 is the way to make SSE fly: https://github.com/tinspin/rupy/wiki/Comet-Stream Old page, search for "event-stream"... Comet-stream is a collection of techniques of which SSE is one. My experience is that SSE goes through anti-viruses better!
Take this for what it's worth, but I see you share rupy on pretty much every thread that mentions WebSockets, and I click on the link pretty much every time, and I still have basically no idea what it is. Documentation probably isn't your priority at the moment, but even just a couple paragraphs could go a long way.
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…
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…
Can you explain what you mean here? What was your peak active user count, what was peak per server instance, and why you think that beats anything else?
Did research on SSE a short while ago. Found out that the mimetype "text/event-stream" was blocked by a couple of anti-virus products. So that was a no-go for us.
How did you find that out?
Earlier quoted context omitted.
I mean you cannot send stuff from client. If you’re using tokens for auth and don’t want to use session cookies, you end with ugly polyfils.
> 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.
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 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!
Before that... yeah, the Firefox dev tools were not very helpful for SSE.
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…
SSE runs over HTTP/3 just as well as any other HTTP feature, and WebTransport is built on HTTP/3 to give you much finer grained control of the HTTP/3 streams. If your application doesn't benefit significantly from that control, then you're just adding needless complexity.
Earlier quoted context omitted.
Sure but then HTTP/3 is still binary and it's in flux meaning most routers don't play nice with it yet and since HTTP/1.1 works great for 99.9% of the usecases I would say it's a complete waste of time, unless you have some new agenda to push. Really people should try and build great things on the protocols we have instead of always trying to re-discover the wheel, note: NOT the same as re-inventing the wheel: http:/…
HTTP/3 is E2E encrypted and built on UDP. What does “most routers don’t play nice with it yet” mean in that context? Do you mean middleware boxes/routers rather than end user routers?
Please elaborate.
My experience with sse is pretty bad. They are unreliable, don’t support headers and require keep-alive hackery. In my experience WebSockets are so much better. Also ease of use doesn’t really convince me. It’s like 5 lines of code with socket.io to have working websockets, without all the downsides of sse.
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…
Which seems to be what you need to send 'headers' after a chunked response.