Ably is a realtime data delivery platform that provides creators the tools to create, deliver, and manage projects. Their main realtime functionality consists of pub/sub, presence, authentication, encryption, and connection state recovery. They consider these services as a part of their real time core:

Realtime API - Ably Real Time Core

Pub/Sub

Ably organizes the message traffic within applications into named channels.  Clients attach to channels to subscribe to messages, and every message publishes to a unique channel broadcast to Ably subscribers.

Presence

This enables clients to be aware of other clients who are “present” on other channels. Each client has a client identifier and connection identifier. There are other options you can add to see other statuses and attributes as well. This presence is great for building applications that focus on multiplayer games. This allows users to see who is and isn’t in the chat.

Encryption

Ably supports built-in symmetric encryption for message content. When TLS is enabled, messages are securely sent and received from Ably. That means they can never be decrypted by Ably, and can only be decrypted by other clients that share the same key as you.

Connection State Recovery

When a client disconnects abruptly, Ably realtime client will automatically try to reconnect the user every 15 seconds. It will continue this process for up to two minutes to recover the client’s connection.

Reactor Queues

Recently they launched Ably Reactor Queues:

“The queues are traditional message queues that allow realtime data published on pub/sub channels to be consumed in a scalable, resilient and efficient way. Reactor queues provide asynchronous machine-to-machine communication that follows a traditional messaging queuing pattern. At a high level, each machine participates in one or both roles: producers (Ably channels) publish messages (data) to a queue; consumers retrieve messages from the queue. The queue service is responsible for: storing published messages by placing them at the back of the queue; picking off the oldest messages from the front of the queue and handing them to a consumer; ensuring a FIFO or ‘first in, first out’ policy is followed; ensuring messages that are consumed successfully are only handed to one of the consumers. This messaging pattern provides decoupling (publishers can publish without waiting for consumers), scalability (adding more consumers increases throughput capacity) and resilience (messages are stored until a consumer has acknowledged the message has been processed successfully).”

Resources

Platform

Examples

Tutorial

Blog

Documentation