Salesforce Streaming API – A Deeper Look

Streaming API is based on Bayeux/Comet/Long polling. Before we go any further on the Streaming API it is necessary to understand the technologies mentioned above on which this integration API is built.

Pull/Push:

HTTP/Web technology is based on the request-response model (i.e. a Pull model in which the client makes a request for data to server and server caters the requested data as response back to client). This model works very well for Client-Server interactions, but suffers to handle the applications that require bidirectional Event/Message flow (e.g. Chat, Notification etc.). To overcome the above limitation Event based flow mechanism is realized over the request-response model and this realization is Bayeux protocol.

Bayeux:

HTTP 1.1 standard requires web clients to support at least 2 simultaneous connections to Server. Bayeux realization of a bidirectional message flow between Client and Server is based on the above fact. In very simple terms here is how the realization works. Client makes a request to Server; the request can carry optional messages from Client. The Server upon receiving the request, processes the message if sent by Client and holds the request in the processing state. Once the Server generates a message to send to the Client, Server makes use of the held request to send the message as a response for that request. Also, when the Server holds the Client’s request, if the Client has to send another message, the Client will make use of the 2nd connection to Server to send the message. The realization ensures that the Server (at the max) holds only one request at any time for seamless message flow between Client and Server. Both the Client and Server needs to queue the messages internally until the connection has availability to send message to the peer.

Advantages:

1. Works on all the browsers that support HTTP 1.1 onwards.
2. Since none of the HTTP standard is violated, no need for port openings or special proxy handling are required.

Disadvantages:

1. Complex for client as well as for Server side implementation.
2. Continuous messaging is needed since Server can’t to hold the Client request indefinitely based on HTTP protocol. (Some browsers timeout the request in 2 minutes if a response is not received.)
3. Implementation has to handle non-available connection for message delivery.
4. Multiple connections between Client and Server.
5. Misuse of web model.

WebSockets: As part of the HTML5, the limitation of bidirectional communication support of Web model is addressed using WebSockets (RFC 6455). WebSocket upgrades the HTTP Connection to WebSockets there by making use of the TCP Bidirectional capability to send messages between Client and Server. WebSocket is currently supported in the latest releases of all major browsers.

Back to Salesforce Streaming API: As we discussed earlier, Bayeux is not a suggested way for bidirectional communication, but is currently widely used because of the wide range of browser support. Salesforce use of Bayeux may be a result of the above reason as well. I strongly believe Salesforce will move towards or provides Streaming API over Websockets in near future.

Things to consider: Streaming API has the following use cases:

1. UI refresh based on data change.
2. Application integration based on Real-time feed.

UI Refresh: Even though most modern Web browser supports 6-8 simultaneous connections to server, HTTP 1.1 requirement is still 2 minimum connections. Always remember Bayeux realization depends on 2 connections. Try to limit the use of one Bayeux channel per webpage. If the app needs more than one Bayeux channel, the preference would be to wrap each Bayeux channel in a separate iframe and use web messaging post message framework for communicating between iframes.

Application Integration: Streaming API doesn’t provide retry and error handling; also timeout requirements are very rigid. As an application integrator always have plan for how to handle dropped connection. Plan for automated reestablishing the subscription, and fetch the missed notifications for processing using other API (SOAP/REST)

Request to Salesforce:

• Instead of requesting developers to use JQuery for establishing Streaming API, it would be better if Salesforce provides a JavaScript API for using Streaming API, similar to Console API or CTI API. Thereby, the solution built over Salesforce will be future proof even if Salesforce moves from Bayeux to WebSockets.

References: Streaming API, Streaming API Timeout, WebSocket RFC