What is Ably?

Ably is a platform that powers realtime digital experiences. Developers can build applications that communicate in realtime without needing to manage things such as scaling, latency, data integrity and network outages using Ably’s SDKs and APIs.

At its core Ably is a cloud-based pub/sub (publish/subscribe) platform-as-a-service (PaaS). It ensures that messages published to Ably by any device will be received, in realtime, by any number of subscribing devices.

Ably provides the realtime capabilities for applications across a wide range of industries, such as EdTech, FinTech, SaaS, sports and entertainment, and healthcare. The most common use cases Ably solves fall into the following categories:

• Chat
• Data broadcast
• Data synchronization
• Multiplayer collaboration

There are various ways to build applications with Ably, however Ably SDKs are the most feature-rich choice. They provide a consistent and idiomatic API across a variety of platforms.

Client connections to Ably are supported over multiple transports, however Ably’s preferred transport is the WebSocket protocol due to its portability and performance. WebSockets enable bi-directional communication between a client and server over a persistent, single-socket connection. Most Ably SDKs use a WebSocket to establish a realtime connection to Ably, and use a simple HTTP request for all other REST operations, including authentication.

The following features are the basic building blocks used to develop realtime applications with Ably:

• Pub/sub channels
• Message storage and history
• Presence
• Push notifications

Channels are the core building blocks of pub/sub. They are used to organize messages into different topics. This enables publishers to send messages to a channel and for subscribers of that channel to receive them. Subscribers will only ever receive the messages on channels they are subscribed to.

Channels support the following message patterns:

• One-to-many, also known as fan out. This is where multiple subscribers receive one message. For example, an application that updates sports fans with game updates, or one that provides travelers with public transport times and status.
• Many-to-one, where multiple publishers send messages to one subscriber. For example, an application monitoring temperature in multiple locations, or one that publishes the location of company vehicles to headquarters.
• Many-to-many, where the number of publishers and subscribers varies. For example, chat applications where direct messaging between two users would use a channel, and a company-wide group chat would use another.

Messages received by Ably are stored in memory for 2 minutes in every location that the channel is active in. This enables Ably 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 up to 72 hours 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. This is a minimum of 2 minutes, up to 72 hours.

For long term storage, you can use an Ably integration to send all, or a subset of messages to your own database or data warehouse.

Ably’s 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.

Push notifications enable messages to be sent to mobile devices without the need for them to establish and maintain a connection to Ably. They are used to notify users who don’t currently have your application open, or aren’t currently using their mobile device.

Ably is built primarily on Amazon EC2 infrastructure. It runs in 7 physical data centers and utilizes 385 points of presence to ensure that there isn’t a single point of failure, nor single point of congestion across the service. Ably is designed to route messages using the least amount of network hops to minimize latency and maximize performance for clients, regardless of their location.

Each data center scales independently to meet the load within that region. Load is dynamically assigned and reassigned across servers in realtime, and the service auto-heals and routes around network failures.

Ably is engineered around the following four principles to ensure the dependability of its service:

• Performance
• Integrity
• Reliability
• Availability