Refactoring from ajax to websockets: recommended patterns and quick wins

Question

I have a single page application that currently uses ajax and REST for talking to the server. I structure the code mostly using promises and deferreds, and I use a pubsub broker to communicate between components. In general, the code is structured to follow Zakas' suggestions for scalable application architecture.

I'd like to move at least some of the interaction with the server into websockets both for performance and ease of development. Some specific interactions I plan to change to use websockets are:

• Chat functionality
• Feedback on long running tasks
• Updates to attributes of currently viewed objects (e.g. someone POSTs to a REST endpoint that corresponds to an object I'm currently rendering)

My question is:

• What are some other quick wins (i.e. websockets >> ajax for a given use case) I should look out for?
• What design patterns are most helpful in structuring websocket code?
• Should some interactions that should stay RESTful ajax calls, or is there a strong case for going 100% websockets?

Thanks.

EDIT

Hera are some related questions I found after I submitted this. These deal most closely with the last part of my question (does going 100% websockets make sense).

• What is the disadvantage of using websocket/socket.io where ajax will do?
• websocket api to replace rest api?
• Why use AJAX when WebSockets is available?
• With websockets, is there a place for AJAX?

Answer 1

As I see it, there are synergies, technical and conceptual advantages of being able to do both PubSub and RPC over a single (WebSocket based) protocol. In fact, we've been developing and are using such a protocol: WAMP.

Here is a FAQ entry of why one protocol, and a blog post that tells a real-life war story of migrating a classical Ajax based to a full WebSocket based solution which is running on WAMP, Autobahn and Crossbar.io.

Disclosure: I am original author of WAMP, Autobahn and Crossbar.io and work for Tavendo.