Product overview

Ably provides multiple interfaces and SDKs to suit different use cases, platforms, and requirements. This guide helps you choose the right approach for your application.

​

Product overview

When building with Ably, you need to make several decisions:

1. Which product: Pub/Sub, Chat, Spaces, LiveObjects, LiveSync, or AI Transport
2. Which features: Rules for per-namespace configuration, push notifications for offline and native push delivery
3. Which interface: REST, Realtime, or protocol adapters

The right choice depends on your application’s requirements for latency, connection persistence, and the complexity of the features you’re building.

​

Ably products

​

Ably Pub/Sub

Pub/Sub is Ably’s core product. It provides flexible, low-level APIs for publishing and subscribing to messages on channels, giving you full control over your message architecture. Use Pub/Sub when you need:

• Maximum flexibility in message structure and channel design
• To build custom realtime features not covered by purpose-built SDKs
• To integrate with existing backend systems

Pub/Sub gives you direct access to Ably’s underlying messaging primitives, including channels, presence, and history, enabling you to design your own message architecture.

​

Ably Chat

Ably Chat provides purpose-built APIs for building chat functionality, including rooms, messages, typing indicators, reactions, and presence. Use Chat when you’re building:

• 1:1 customer support chat
• Group conversations
• Livestream chat with thousands of users
• Any application requiring chat functionality

Chat SDK features:

​

Ably Spaces

Ably Spaces provides high-level APIs for building collaborative environments where users work together in realtime. Use Spaces when you’re building:

• Interactive whiteboards with live cursors
• Collaborative document editing
• Avatar stacks showing online users
• Applications with component locking to prevent edit conflicts

The Spaces SDK is optimized for participant state, which is largely ephemeral and doesn’t need to be stored. This is distinct from application state, which must be validated and stored in your database. Spaces SDK features:

​

Ably LiveObjects

Ably LiveObjects provides the ability to associate durable state with a channel. Participants can use and modify that state concurrently, with conflicts resolved automatically. Use LiveObjects when:

• The state is more naturally represented as a structured collection of objects and/or primitive values
• Your application needs a way to structure and manage the state explicitly

LiveObjects features: Pub/Sub channels, without LiveObjects, can also be used as a durable store of channel state, but in this case the state is simply the content of messages sent on the channel.

​

Ably LiveSync

Ably LiveSync synchronizes your database state to frontend clients in realtime, whilst having only a single write path. Use LiveSync when:

• Your database is the source of truth for application state
• You need to reflect database changes to clients in realtime
• You want to enable optimistic updates in the UI
• You’re using PostgreSQL or MongoDB

LiveSync automatically streams changes you make in your database to clients to keep them in sync with the source of truth in your database.

​

Ably AI Transport

Ably AI Transport provides purpose-built APIs for streaming AI-generated content to users in realtime, handling token streaming, session management, and multi-user fan-out. Use AI Transport when:

• You’re building applications that stream LLM responses to users in realtime
• You need to manage AI chat sessions with identity and resumability
• You want to fan out AI-generated content to multiple subscribers

​

Why use purpose-built SDKs

Purpose-built SDKs provide an API optimized for specific use cases:

​

REST vs Realtime interface

Ably SDKs contain both a REST and a Realtime interface. Each serves different use cases.

​

REST interface

The REST interface communicates with Ably using HTTP and is effectively stateless. It does not maintain a persistent connection to Ably. Use the REST interface when you need to:

• Publish messages from a server without receiving updates
• Issue tokens on behalf of other clients
• Retrieve message history, presence history, or application statistics
• Perform occasional, request-response style operations
• Minimize resource usage in environments where persistent connections are impractical

The REST interface is more commonly used server-side. It is more efficient if you don’t need to establish a persistent connection to Ably.

​

Serverless and cloud functions

Use the REST interface when publishing from serverless environments such as:

• AWS Lambda
• Google Cloud Functions
• Azure Functions
• Cloudflare Workers

These environments are designed for short-lived, stateless execution and do not support persistent WebSocket connections.

​

Realtime interface

The Realtime interface uses an Ably-defined protocol, primarily over WebSockets, to establish and maintain a persistent connection to Ably. The Realtime interface extends the functionality of the REST interface. Use the Realtime interface when you need to:

• Subscribe to messages in realtime
• Maintain a persistent connection to Ably
• Attach to one or more channels and publish and subscribe to messages
• Register presence on a channel, or listen for others present in realtime
• Publish at very high message rates, or with the lowest possible latencies
• Benefit from automatic reconnection and connection state recovery

The Realtime interface is most commonly used client-side. Subscribing to messages is only available through the Realtime interface.

​

Comparison

​

REST HTTP API vs SDK REST interface

Ably provides a REST HTTP API that you can use directly without an SDK. Use the REST interface of an Ably SDK when:

• You want automatic re-routing around network problems via alternative datacenters
• You prefer a language-idiomatic API

Use the REST HTTP API directly when:

• No Ably SDK is available for your platform
• You want to avoid having any third-party SDK in your app

​

Protocol adapters

Ably SDKs are the recommended method for connecting to Ably. They provide comprehensive feature support including automatic connection management, authentication token renewal, and APIs for the full range of Ably functionality. Protocol adapters offer an alternative for specific scenarios where SDKs are impractical.

​

When to use SDKs

Use an Ably SDK when:

• An SDK is available for your platform
• You need the full set of Ably features
• You want automatic connection recovery and token renewal
• You’re building a production application

​

When to use protocol adapters

Consider protocol adapters when:

• There is no Ably SDK available for your platform (such as embedded or IoT devices)
• You are migrating from another messaging service (such as Pusher or PubNub)
• You want to avoid including any third-party SDK in your own application

Available protocol adapters:

​

Combining SDKs with Pub/Sub

Purpose-built SDKs like Chat and Spaces are built on top of the Ably Pub/Sub SDK. When you initialize a purpose-built SDK, it creates or accepts an underlying Ably Realtime client. This means you can use that same client to interact with Pub/Sub channels directly, sharing a single connection to Ably rather than opening multiple connections.

​

Benefits of combining SDKs

• Authentication and connection management are handled by the underlying SDK
• You maintain a single connection to Ably rather than multiple connections
• You can extend your application’s functionality with custom Pub/Sub features alongside the purpose-built SDK

​

When to combine SDKs

Combine a purpose-built SDK with Pub/Sub when:

• The SDK covers most of your requirements but lacks a specific feature
• You need to build custom functionality that integrates with SDK-managed features
• You want to publish or subscribe to custom channels alongside SDK-managed channels

​

Example use cases

The following are examples where combining the Chat SDK with Pub/Sub is effective:

​

Best practices

When combining SDKs with Pub/Sub:

• Use consistent authentication: Let the purpose-built SDK manage authentication and share its Realtime client
• Avoid duplicating SDK features: If the Chat SDK provides typing indicators, use them rather than building your own
• Namespace your custom channels: Use a clear naming convention to distinguish custom Pub/Sub channels from SDK-managed channels
• Consider message ordering: Messages on SDK-managed channels and custom Pub/Sub channels are independent
• Handle connection state once: The underlying Realtime client manages connection state

​

Next steps