Realtime client library for Ably, the realtime messaging service
npm install ably!Ably Chat Header
---
engines in package.json. |
sh
npm install ably
`
You can also source it directly in your HTML. (This url will point to the latest version of v2 of the SDK, the current major version, avoiding breaking changes per semver)
`html
`
Usage
The following code connects to Ably's realtime messaging service, subscribes to a channel to receive messages, and publishes a test message to that same channel.
`javascript
// Initialize Ably Realtime client
// (for the REST client use new Ably.Rest({...}) instead)
const realtimeClient = new Ably.Realtime({ key: 'your-ably-api-key', clientId: 'me' });
// Wait for connection to be established
await realtimeClient.connection.once('connected');
console.log('Connected to Ably');
// Get a reference to the 'test-channel' channel
const channel = realtimeClient.channels.get('test-channel');
// Subscribe to all messages published to this channel
await channel.subscribe((message) => {
console.log(Received message: ${message.data});
});
// Publish a test message to the channel
await channel.publish('test-event', 'hello world');
`
Modular variant
The Pub/Sub SDK has a modular (tree-shakable) variant to build with a small bundle sizes.
Modular variant details.
Aimed at those who are concerned about their app's bundle size, the modular variant of the library allows you to create a client which has only the functionality that you choose. Unused functionality can then be tree-shaken by your module bundler.
The modular variant of the library provides:
- A BaseRealtime class;
- various plugins that add functionality to a BaseRealtime instance, such as Rest, RealtimePresence, etc.
To use this variant of the library, import the BaseRealtime class from ably/modular, along with the plugins that you wish to use. Then, pass these plugins to the BaseRealtime constructor as shown in the example below:
`javascript
import { BaseRealtime, WebSocketTransport, FetchRequest, RealtimePresence } from 'ably/modular';
const client = new BaseRealtime({
key: 'YOUR_ABLY_API_KEY', // Replace with a real key from the Ably dashboard
plugins: {
WebSocketTransport,
FetchRequest,
RealtimePresence,
},
});
`
You must provide:
- At least one HTTP request implementation; that is, one of FetchRequest or XHRRequest;
- At least one realtime transport implementation; that is, one of WebSocketTransport or XHRPolling.
BaseRealtime offers the same API as the Realtime class described in the rest of this README. This means that you can develop an application using the default variant of the SDK and switch to the modular version when you wish to optimize your bundle size.
In order to further reduce bundle size, the modular variant of the SDK performs less logging than the default variant. It only logs:
- Messages that have a logLevel of 1 (that is, errors)
- A small number of other network events
If you require more verbose logging, use the default variant of the SDK.
For more information view the TypeDoc references.
---
Contribute
Read the CONTRIBUTING.md guidelines to contribute to Ably.
---
Releases
The CHANGELOG.md contains details of the latest releases for this SDK. You can also view all Ably releases on changelog.ably.com.
---
Support, feedback, and troubleshooting
For help or technical support, visit Ably's support page or GitHub Issues for community-reported bugs and discussions.
$3
Ably Pub/Sub works out-of-the-box in background scripts for Chrome extensions using manifest v2. However, since manifest v3 background pages are no longer supported, you will need to run Ably Pub/Sub JavaScript SDK inside a service worker.
Chrome extensions support details.
If you are using this SDK in a service worker, note:
- In versions of Chrome before 116, active WebSockets would not reset the 30s service worker idle timer, resulting in the client being closed prematurely.
- In versions 116 and above, service workers will stay active as long as a client is connected.
To ensure compatibility, add the following to your manifest.json:
If you are using this SDK's realtime features, for example, WebSockets in a service worker, note:
- In versions of Chrome before 116, active WebSockets would not reset the 30s service worker idle timer, resulting in the client being closed prematurely.
- In versions 116 and above, service workers will stay active as long as a client is connected.
To ensure compatibility, add the following to your manifest.json:
`json
{
// ...
"minimum_chrome_version": "116"
// ...
}
`
$3
If you're hitting a "connection limit exceeded" error and see rising connection counts in your Ably dashboard, it's likely due to multiple Ably.Realtime instances being created during development.
"Connection limit exceeded" support details.
Even for use client components, Next.js may execute them on the server during pre-rendering. This can create unintended Ably.Realtime connections from Node.js that remain open until you restart the development server.
Prevent server-side connections using autoConnect and a window check:
`typescript
const client = new Ably.Realtime({
key: 'your-ably-api-key',
autoConnect: typeof window !== 'undefined',
});
`
Creating the client inside React components can lead to a new connection on every render. To prevent this, move the new Ably.Realtime() call outside of component functions.
In development environments that use Hot Module Replacement (HMR), such as React, Vite, or Next.js, saving a file can recreate the Ably.Realtime client, while previous instances remain connected. Over time, this leads to a growing number of active connections with each code edit. To fix: Move the client to a separate file (e.g., ably-client.js) and import it. This ensures the client is recreated only when that file changes.
$3
If you encounter a Failed to compile Module not found error or warnings related to keyv when using Ably Pub/Sub JavaScript SDK with Next.js, add ably to the serverComponentsExternalPackages list in next.config.js.
Next.js with App Router and Turbopack support details.
The following example adds ably to the serverComponentsExternalPackages list in next.config.js:
`javascript
const nextConfig = {
// ...
experimental: {
serverComponentsExternalPackages: ['ably'],
},
};
`
The issue is coming from the fact that when using App Router specifically, dependencies used inside Server Components and Route Handlers will automatically be bundled by Next.js. This causes issues with some packages, usually the ones that have complex require statements, for example, requiring some packages dynamically during runtime. keyv is one of those packages as it uses require statement dynamically when requiring its adapters (see code in repo):
keyv ends up being one of ably-js's upstream dependencies for the node.js bundle, which causes the errors above when using it with Next.js App Router.
Using serverComponentsExternalPackages opts out from using Next.js bundling for specific packages and uses native Node.js require instead.
This is a common problem in App Router for a number of packages (for example, see next.js issue vercel/next.js#52876), and using serverComponentsExternalPackages is the recommended approach here.
$3
If you encounter an error such as connection limit exceeded during development, it may be caused by several issues.
General errors support details.
#### Server-side rendering (SSR)
Use the autoConnect option to prevent the client from connecting when rendered on the server:
`typescript
const client = new Ably.Realtime({ key: 'your-ably-api-key', autoConnect: typeof window !== 'undefined' });
`
#### Component re-renders
Avoid creating the client inside React components. Instead, move the client instantiation outside of the component to prevent it from being recreated on every render.
#### Hot module replacement (HMR)
To avoid duplicate client instances caused by hot reloads, move the new Ably.Realtime() call into a separate file, for example, ably.js` and export the client from there. This ensures a single shared instance is reused during development.