4 ms·
Yes most servers support websockets. But unfortunately most proxies and firewalls do not, especially in big company networks. Suggesting my users to use SSEs fo
by realPubkey 2y ago
Yes most servers support websockets. But unfortunately most proxies and firewalls do not, especially in big company networks. Suggesting my users to use SSEs for my database replication stream solved most of their problems. Also setting up a SSE endpoint is like 5 lines of code. WebSockets instead require much more and you also have to do things like pings etc to ensure that it automatically reconnects. SEEs with the JavaScript EventSource API have all you need build in:
https://rxdb.info/articles/websockets-sse-polling-webrtc-webtransport.html https://rxdb.info/articles/websockets-sse-polling-webrtc-web...
- the_mitsuhiko 2y agoSSE also works well on HTTP/3 whereas web sockets still don’t.
- apitman 2y agoI don't see much point in WebSockets for HTTP/3. WebTransport will cover everything you would need it for an more.
- the_mitsuhiko 2y agoThat might very well be but the future is not today.
- apitman 2y agoBut why add it to HTTP/3 at all? HTTP/1.1 hijacking is a pretty simple process. I suspect HTTP/3 would be significantly more complicated. I'm not sure that effort is worth it when WebTransport will make it obselete.
- the_mitsuhiko 2y agoIt was added to HTTP/2 as well and there is an RFC. (Though a lot of servers don’t support it even on HTTP/2) My point is mostly that SSE works well and is supported and that has A meaningful benefit today.
- leni536 2y agoTo have multiple independent websocket streams, without ordering requirements between streams.
- deaf_coder 2y agogoing slightly off the tangent here, does FaaS cloud providers like AWS, CloudFlare, and etc support SSEs? Last time I checked, they don't really support it.