Dabbling in the messaging over Websockets waters

by mort

Doing some research into non-trivial messaging over Websockets at the moment, for the push-y parts of a restful API.

The core decision I have to make is how to best approach using WS to transport not only trivial (i.e. chat) payloads, but richer ones including attached metadata and different message types. A somewhat different, but directly related, problem is deciding how many websocket channels you are gonna use per-client: you can either set up different channels for different types of messages (one for user chats, another for delivering user notifications, a third for delivering global notifications), or merge several of those into a single channel and letting the client operate on incoming messages and decide the pertinent thing to do on a per-message basis.

About the message format stuff, the most useful info I’ve found so far is probably this New Bamboo, an ace blog on all things real-time, post, about a custom JSON based format for modeling events over Websockets, as a lightweight alternative to things like STOMP. The use of a convention in the format of the JSON allows for some clever dynamic handling of incoming messages that opens some really nice possibilities. And, of course, some people are already working on XMPP over Websockets, as a replacement for BOSH

As for the multi vs. single websockets endpoint for different types of messages between apps, I think I find more advantages in a single endpoint and delegating on client and server the responsibility of discerning between message types and deciding the appropriate handling logic.

Let the research and experimentation continue. Real-time is lots of fun.