About Pub/Sub

Ably Pub/Sub is Ably’s core product. It’s flexible APIs are powerful building blocks that you can use to create any realtime experience with.

The following features are some of the basics that you need to develop realtime applications:

Ably Pub/Sub enables you to implement the publish-subscribe (pub-sub) pattern. Any number of publishers can send messages to a channel, and any number of subscribers can receive those messages. Publishers and subscribers are completely decoupled from one another.

Channels are used to separate messages into different topics. Messages contain the data that a client is communicating, such as the contents of an individual chat message, or an event that has occurred, such as updated financial information. Whilst billions of messages may be delivered by Ably, clients receive only the messages on the channels they subscribe to.

The presence feature enables clients to be aware of other clients that are currently “present” on a channel. Subscribers receive three types of updates from presence members. These are when a client joins the presence set, when they leave the presence set, and when they update an optional payload associated with each member. The payload can be used to describe their status, or attributes associated with them, such as setting their status to ‘out for lunch’.

Presence is most commonly used as an online indicator to create an avatar stack for an application, or to notify occupants of a chat room that a member has joined or left.

Messages received by Ably are stored in memory for 2 minutes in every location that the channel is active in. This enables Pub/Sub SDKs to automatically retrieve them in the event of network connectivity issues, or a lost connection, as long as the connection is re-established within 2 minutes.

Messages can be stored for much longer on disk by Ably through additional configuration. The history feature can be used to retrieve previously sent messages as a paginated list. History can retrieve messages from as far back as the message persistence configured for a channel.

Push notifications notify user devices whether or not an application is open and running. They deliver information, such as app updates, social media alerts, or promotional offers, directly to the user’s screen.

Ably sends push notifications to devices using Google’s Firebase Cloud Messaging service (FCM) and Apple’s Push Notification Service (APNs). Push notifications don’t require a device to stay connected to Ably. Instead, a device’s operating system maintains its own battery-efficient transport to receive notifications.

You can publish push notifications to user devices directly or via channels.

Pub/Sub SDKs provide a consistent and idiomatic API across a variety of supported platforms and are the most feature-rich method of integrating Ably into an application. Ably SDKs contain a realtime and a REST interface, each of which can be used to satisfy different use cases.

The REST interface communicates with Ably using the HTTP protocol and is effectively stateless. The REST interface provides a convenient way to access the REST HTTP API and is intended to be used by clients that don’t require realtime updates. It is more commonly used server-side. It is used to:

  • publish messages
  • publish messages on behalf of other clients
  • issue tokens on behalf of other realtime clients
  • retrieve persisted messages, presence history and application usage statistics

The realtime interface is implemented using an Ably-defined protocol, primarily over WebSockets. It enables clients to establish and maintain a persistent connection to Ably. The realtime interface extends the functionality of the REST interface and is most commonly used client-side. It is used to:

  • maintain a persistent connection to Ably
  • attach to one or more channels, and publish and subscribe to messages to them
  • register their presence on a channel, or listen for others present in realtime
  • publish at very high message rates, or with the lowest possible realtime latencies

Interacting with the REST HTTP API directly is fully supported. However, Ably recommends using the REST interface of an SDK where possible, as they provide additional features that improve performance and resilience that the REST HTTP API can’t deliver on its own. This includes automatic re-routing around network problems by using alternative data centers.

Whilst SDKs are the recommended method of integrating Ably in the majority of cases, there are alternatives available when your use case requires it.

They are less feature-rich than SDKs, however they require fewer resources in terms of memory and network overhead to run. They can also be used to build applications using frameworks that don’t have an available Ably SDK.

The following other protocols are supported:

MQTT
translate between the Message Queuing Telemetry Transport (MQTT) and Ably’s own protocol. Often used in remote devices with small footprints.
SSE
use Server Sent Events (SSE) to get a realtime stream of events from Ably, where using a full SDK is impractical. Often used when you have stringent memory restrictions and only need to subscribe to events, not publish them.
Pusher Adapter
quickly migrate from Pusher to Ably using the Pusher Adapter.
PubNub Adapter
quickly migrate from PubNub to Ably using the PubNub Adapter.