“Three main choices for advanced communications in HTML5“, which I posted two months ago, excluded one obvious candidate for “advanced communications”: HTML5‘s server-sent events (SSE). To my surprise, no reader asked me why. Despite this, it’s time to explain SSEs, why I didn’t mention them earlier, and why they are particularly interesting for real-user monitors and related datacenter “dashboards”.
Start with a peek at this example. Most will see a little digital clock which reports the time on one of our servers, updated every second; the background color of the display cycles red-yellow-green as the display updates.
What good is that?! In isolation, it doesn’t look like much; it was (barely) possible to create similar effects with browsers fifteen years ago, and there are surely already enough clocks in the world. As a model for applications that help in the datacenter, though, this small demonstration has a lot going for it:
- server-side requirements are as minimal as can be. The supporting executable in this case is twelve lines of
bash, and, at the cost of a little obfuscation, it could be reduced to five. No particular language or library is required; SSE is another one of the interesting features fully available to simple-minded CGI coders using twenty-year-old technology.
- Transport is by way of good-old HTTP, so SSE travels well through typical enterprise networks.
- With one notable exception, which I explain below, the demonstration performs well in all sorts of environments, including smartphones, tablets, and a range of old and new laptops in our office.
- SSE’s “push” is just the right kind of programming for many cases that interest me. I often need Web applications with the intelligence to display useful information, but also update that information as new results–a misconfiguration of a customer account, an overfull filesystem, congestion on a subnet, or so on–arrive.
What’s the catch?
With all this going for it, why didn’t I include SSE in my earlier list of established HTML5 communication methods? Internet Explorer (IE) doesn’t support SSE, and I’ve found no one who claims to know of a definite plan for a future version of IE to do so. In the context of conventional Web application development, that’s enough of a reason on its own to decide against even a documented W3C standard.
SSE has other blemishes. It’s had a reputation for memory leaks, which I’ve never made the time to analyze for myself. SSE is a unidirectional communication, and many of today’s sexiest applications seem to fit a two-way “chat” better.
Easy to start
Still, plenty of shims are available to extend SSE support to IE, memory leaks are correctable, SSE’s light resource demands are appealing, its minimalism is a good fit for all the devops who aren’t full-time programmers, devops staffs don’t require IE compatibility, and a simple push is the right approach for a lot of what we do in the datacenter. Try SSE for yourself; it should take only a few minutes to put together a “
Hello, World!” that makes sense in your environment. With that in hand, you’ll be in a position to judge what SSE can do for your next projects.