5 ms·
I've always had a bit of a soft spot for Server Sent Events. Just simple and easy to use/implement.
by kellengreen 3y ago
I've always had a bit of a soft spot for Server Sent Events. Just simple and easy to use/implement.
- djbusby 3y agoWorks with bog-standard Apache prefork and PHP.
- marban 3y agoAbsolutely underrated.
- ajvpot 3y agoI agree. Unfortunately you can only have 6 SSE streams per origin per browser instance, so you may be limited to 6 tabs without adding extra complexity on the client side. https://crbug.com/275955 https://crbug.com/275955
- simonw 3y agoIs that true if you are using HTTP/2?
- cassepipe 3y agoNope. That's only a problem with HTTP/1.1
- hobobaggins 3y agoYes, but the limit is different (usually much higher) and negotiated, up to maximum SETTINGS_MAX_CONCURRENT_STREAMS (which is fixed at 100 in Chrome, and apparently less in IOS/Safari.)
- andrewmutz 3y agoYou can get around that limit using domain sharding, although it feels a bit hacky.
- TheP1000 3y agoIs above still an issue with http2/3? edit: From the article: To workaround the limitation you have to use HTTP/2 or HTTP/3 with which the browser will only open a single connection per domain and then use multiplexing to run all data through a single connection.
- gorjusborg 3y agoNo, if you can enable TLS and HTTP/2|3, you are only technically using a single browser connection, onto which multiple logical connections can be multiplexed. I think the article calls this out. There is still a limit on the number of logical connections, but it's an order of magnitude larger.
- ravxx 3y agojust use a service worker to share state, you would be much better off doing this anyways. saves a ton and is performant.
- simonw 3y agoI think you need a SharedWorker for that rather than a service worker https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker https://developer.mozilla.org/en-US/docs/Web/API/SharedWorke...
- jedschmidt 3y agoA service worker would work fine; the connection would be instantiated from the SW and each window/worker could communicate with it via navigator.serviceWorker.
- esprehn 3y agoThat doesn't work because browsers have duration limits on ServiceWorkers: https://github.com/w3c/ServiceWorker/issues/980#issuecomment-782094985 https://github.com/w3c/ServiceWorker/issues/980#issuecomment... Also unfortunately Chrome doesn't keep SharedWorker alive after a navigation (Firefox and Safari do): https://issues.chromium.org/issues/40284712 https://issues.chromium.org/issues/40284712 Hopefully Chrome will fix this eventually, it really makes it hard to build performant MPAs.
- jedschmidt 3y agoIn my experience, as long as a controlled window is communicating with the SW, the connection will remain alive.
- nchmy 3y agoShared workers (inexplicably) dont exist on Android Chrome https://issues.chromium.org/issues/40290702 https://issues.chromium.org/issues/40290702
- nine_k 3y agoCan the tabs share a background worker that would handle that?
- merb 3y agoYou can use https://www.npmjs.com/package/broadcast-channel https://www.npmjs.com/package/broadcast-channel which creates a tab leader, no need for a background worker Edit: of course you could use: https://caniuse.com/sharedworkers https://caniuse.com/sharedworkers but android does not support it. We migrated to the lib because safari took its time… so mobile was/is not a thing for us
- nchmy 3y agoHere's the chrome android issue for Shared Workers. Add your voice if it is something you need https://issues.chromium.org/issues/40290702 https://issues.chromium.org/issues/40290702
- paulddraper 3y agoHTTP 2/3 doesn't have they limitation. For HTTP 1, simply shard the domain.
- xialvjun 3y agojust one tab use SSE and others use storage event.
- shams93 3y agoWith ipv6 they can now be fully scaled easily but they are absolutely awesome, much easier to scale because you can give your client a simple list of sse services and its essentially stateless if done right. Websockets get really complex to scale past a certain level of use.
- apitman 3y ago> With ipv6 they can now be fully scaled easily Any day now: https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html
- freedomben 3y agois anybody actually able to disable ipv4? maybe if you only serve vpn or internal users? This might be the best thing about Elixir/Phoenix LiveView. I haven't actually had to care in quite some time :-) (though to be fair, I keep things over the websocket pretty light)
- nijave 3y agoYeah there's 6to4 schemes. It's common in the U.S. for cell providers to give IPv6 but private IPv4 and do NAT (although IPv4 could be skipped altogether) AWS you can use NAT Gateways for 6to4 and do v6 only subnets
- bawolff 3y agoWhat does ipv6 give you that virtual hosts don't?
- spintin 3y agoSSE are really a subset of Comet-Stream (eternal HTTP response with Transfer-Encoding: chunked) only they use a header (Accept: text/event-stream) and wraps the chunks with "data:" and "\n\n". But yes it's the superior (simplest, most robust, most performant and scalable) way to do real-time for eternity. The browser is dead, but SSE will keep on doing work for native apps.
- paulddraper 3y agoThe downside is that you have to base64 payloads or otherwise remove newlines. I wonder why they didn't just a multipart streamed response. Supports my metadata, very commonly implemented format
- niutech 2y agoNo need to base64 everything if you can just escape the new lines. Or you can use https://github.com/luciopaiva/binary-sse https://github.com/luciopaiva/binary-sse
- fswd 3y agodon't forget the timeout reconnect!
- afavour 3y agoAlso because they’re so simple you can use a CDN to scale them way more easily than you can WebSockets: https://www.fastly.com/blog/server-sent-events-fastly https://www.fastly.com/blog/server-sent-events-fastly
- Alifatisk 3y ago> SSE connections keep a mobile device’s radio powered up all the time. You should avoid connecting a SSE stream on a device that has a low battery, or possibly avoid using SSE at all unless the device is plugged in. Damn, that’s a huge downside
- afavour 2y agoSame applies to websockets, but yeah.
- Nasreddin_Hodja 2y agoBut isn't your device’s radio powered up all the time anyway?
- Alifatisk 2y agoI think it’s on all the time but the phone has different power levels that it gives the radio, all this to optimize the battery usage. So depending on how much the phone needs to utilizes the radio, the higher the power level is? That’s just my theory though.
- Nasreddin_Hodja 2y agoI don't think keeping sockets open waiting for incoming data have big impact on battery usage because there is no data transmission at that moment so radio shouldn't consume much energy in stand-by mode. I use K9-Mail app for email working 24h a day, it has multiple accounts on different IMAP4 servers. You know, IMAP requires one keep-alive socket per subscribed folder and I have no problem with battery usage.