You may not need Server Sent Events, either, depending on what “real time” means to you - sometimes it really means “less than a minute”, or just “faster than our competitor”. I’d always start with polling, unless I was sure it wasn’t going to work.
I’ve also been wondering whether one can poll with HTTP persistent connections that delay the response for as long as possible. What do you think?
What you’ve described is what the author of the article (and others) call long polling. It definitely works! There are some downsides especially for mobile devices, but it’s definitely a viable approach in many situations.
Yeah, it’s what everyone was using before SSE came out.
Long polling is strictly worse. It’s just like SSE, except the connection is restarted on every message.
I’d appreciate it if you’d describe why it’s worse. Why does the connection need to be restarted? An HTTP persistent connection wouldn’t need to be restarted would it? You’d need to send the HTTP header again but not the TCP handshake.
Er, I don’t mean the TCP connection, that can be kept alive, sure. Yes, the HTTP request (which is a “connection” conceptually on both sides) is restarted.
Interesting. Is it really so expensive restarting an HTTP connection?
Technically not very expensive, but a) just feels like a horrible hack and b) pretty much always requires custom state tracking (like requesting messages since a timestamp) – with SSE, you only need that if you want resuming. You have an open stream on the server side, you just write into it whenever you want and data comes out on the other end.
I recently switched to messaging instead of using APIs I pull from or websocketd. I use MQTT (on mosquitto) pour RabbotMQ.
Once you digest the asynchronous nature of the communication it is a fantastic solution.
I’m interested if http2 data frames change this picture significantly or not - trade offs for mobile support and cpu or memory usage both at client and server, reconnection in face of unreliable intermediate proxies.