Are web sockets ready to deploy?

In short I say the answer is "yes". 


18m ago we needed to add a notification service to our platform. We were adding an Android and Flash clients to the CloudTalk platform and neither platform supported iOS style notifications at the time. We weren't too excited about a long polling solutions since we didn't want to tie up our API request servers with this kind of transaction. We wanted something like websockets, but websockets were not ready at the time; we are early adopters but there was nothing yet to adopt except a commitment to help develop the technology. We settled on building our own "push server" that operated in much the same way as websockets; open a connection to the push server and just hang there waiting for events to stream down. We kept it super simple expecting that at some point we'd upgrade the protocol to websockets when they were more mature. The big lack with our solution was that we couldn't provide notifications in a browser without Flash, but since at the time our web solution was built in flash, this wasn't a problem at the time.


In our system, When an app client registers as being on line it's given an address to connect to for notifications and they wait on the connection for  payloads that are delivered in JSON. The client has a small vocabulary used to validate and check status. We've been really happy with this solution and if we weren't looking for a way to implement notifications on mobile web devices where flash isn't practical (this includes Android too folks) we'd probably let our solution roll on, but we do want to support web apps that don't require flash. So, it was time to look at that "upgrade" to websockets. What I found is that there is fast moving support for websockets in browsers (see Caniuse); but, not all browsers and client libraries support the same handshake protocol levels and there are bugs, so it can be a bit of a task getting a server side set up to handle all the differences. 


There are a few of bright spots here, and ironically for me one of these is a Flash component  web-socket-js (this is a nice bit of code) that you can install in a browser that implements a stable version of the websocket handshake protocol. This takes care of all non-mobile devices, so now it's mobile Safari and mobile Chrome that have to be supported which is still going to be a task as there a lot of phones running old software.


The second bright spot is the server side. There is a lot going on here too. We were happy to see that Jetty7 has native support, but pretty much every platform you might use has got at least a library that works stackoverflow - websocket-for-html5, though if you choose a solution without source code you're gonna hurt when one of those jenky clients hooks up and you cannot fix the problem. There is one way forward on the server side that I think everyone should be looking at and that's jumping on Node.js. This Node package  node-websocket-server rocks. You can be up and running in minutes and putting together websocket serverside code just a few minutes later. Node has really changed my point of view about creating a system of cooperating services and the support ecosystem is exploding  (I'll write more about that in another post) 


Lastly, the native support on the client side is starting to gel. iOS has support already and there are libraries that will enable Android native apps as well (no concrete info on whether native support in the Android SDK yet). This is good. We've never been particularly happy with the timeliness of iOS notifications and it would be good if we can get all of our native apps all tied into the same system. 


At this point it looks to me like it is possible to provide decent support using websockets, you will be challenged by some clients but it's doable and taking into account how easy you can setup a websocket service with platforms like Node it's definitely a "go for it" decision.