Salesforce Streaming API

[chulkilee]

Introducing Streaming API

Salesforce Streaming API is based on Bayeux / ComeD. Unfortunately, I couldn't find a library to handle that :(

[zblanco]

It's 7 years since the last commit, but there's an Erlang library that might work: https://github.com/antoniogarrote/erlfaye

[chulkilee]

I'm not super clear how Bayeux / Cometd / Faye relate to each other..

Faye says:

Faye is based on the Bayeux protocol, and is compatible with the reference implementation of Bayeux provided by the cometD project.

so I guess any Faye library can be used - I found another one in elixir: https://github.com/messagerocket/pixie

[zblanco]

Faye is used in Restforce, the Ruby library I'm working with currently. It's known to only work with a specific version. I wonder why the implementation is so finicky?

It looks like Pixie is still on Elixir 1.3 and could probably use some updates.

I'd love to be using Elixir for this Salesforce integration project I'm working on. Elixir makes more sense than Rails to being a sort of reactive API-consumer middle-layer which is what the use case revolves around.

[chulkilee]

@MRDoops I'm on the same boat :)

I'm not using Salesforce streaming api, but even so I'm not sure I want to implement it if there is no good library I can use. My use cases do not need to create topic dynamically, so I may create topics and subscribe with other tool (e.g. java, I assume the best support for this), and use different pubsub mechanism (e.g. kafka or whatever).

Another option is to write APEX class and code to call my api back, but that has different challenges of deployment, monitoring, logging, etc.

[zblanco]

Salesforce itself provides the server mechanisms for the CometD/Bayeux Protocol implementation. The Pixie repo implements both the server and client portions, but it's still worth referencing. For ExForce, we'd only need to implement a client that can pub/sub and handle re-connections. Good description of how Faye implements it here.

This documentation from Salesforce is probably the most succinct description of the implementation requirements for a Salesforce specific CometD client.

From what I can tell we'll want a persistent processes listening to channels like meta/handshake channel to handle messages from the server informing of re-connections, network failures, and handshake success/failure. Then maybe a dynamic supervisor to spawn listener processes to an individual topics/subscription that implement the long polling. The Java CometD code is worth checking out.

[fullstackpiyush]

Hi,
How can I be helpful to this issue..
Is it resolved?

[chulkilee]

@fullstackpiyush no, it's not implemented. I'm not using this feature, so I don't have a plan to work on it - please feel free to take a look and create PR. Thanks!