Idempotent publishing now enabled in all Ably 1.1 client library SDKs

Idempotent publishing (docs) is now enabled in all Ably 1.1 Client Library SDKs. This elimimates the risk of duplicate messages.

What is idempotent publishing?

Idempotent REST publishing ensures that a failed publish due to a network failure, or any other failure, can safely be retried without worrying that a message may be published more than once.

In effect, we’re adding exactly-once semantics to our REST publishes over a protocol (HTTP) that has historically had shortcomings at a protocol level in regards to idempotent operations.

The problem is that POST, which is most commonly used to create or upload resources, is not guaranteed to be idempotent. Therefore, HTTP clients that send a POST request to a server more than once should expect multiple results.

In the world of distributed systems and services that provide contracts in terms of what onwards processing happens for POST requests, this can be a considerable problem. For example, if an HTTP client is publishing a message containing transaction details into a pub/sub system that is then in turn broadcasting that message to subscribers, publishing the message multiple times will mistakenly result in the transaction being processed multiple times.

Ably's idempotent publishing solves this.

Read the full documentation or the deep dive idempotency concept article.

Note: When we released the Ably 1.1 client library SDKs, idempotent publishing was supported in all libraries but wasn't yet enabled. If you're already using a 1.1 library there's no need to need to upgrade.

Ably client library SDK releases and updates - 1.1.1

  • .NET 1.1 is released.
  • New Java 1.0.13 and 1.1. releases. Improves handling of clock skew #462 among other changes. Full changelog.

Any questions, get in touch.

Send native cross-platform, cross-device push notifications with Ably

Ably Push Notifications graduate from beta to general availability.

With this release the Ably Client Library SDKs gain a simple, unified Push Admin API (docs). Send notifications over existing Ably channels to all subscribed devices, or deliver direct to individual devices using the Ably REST Publishing API. Ably does all the heavy lifting in the background to deliver messages reliably and instantly via APNs or FCM.

In a few lines of code you can register a device, subscribe to push notifications, and publish a push notification from your server. This makes it much easier and simpler to add iOS and Android push notifications to your Ably apps and send native notifications to your users.

Read the announcement blog, head over to the documentation for more detail, or get going right away with tutorials.

As always, let us know if you've any questions.

Test Reactor rules from the Ably dashboard

The Ably Reactor provides data stream processing pipelines to easily link the Ably network to your other systems.

Setting up pipelines is a simple matter of configuring rules in the Ably dashboard. But testing those rules has been a bit trickier, requiring the dev console or command line to do so.

As of today you’ll find a test option in the rule management dashboard.

With a single button click you can test a rule and receive rapid feedback on whether it works or not. No more dev console or command line.

Screenshot 2019-03-13 at 10.38.21.png

This will greatly speed up the initial configuration process and provide increased clarity on whether rules are operating as intended. Future edits and debugging will also be much easier.

Head over to your dashboard to see the new testing in action. If you’ve got any questions we’d be happy to help.

Ably Javascript client library release 1.1.4

  • Support PUSH, PATCH, and DELETE in Rest#request()
  • Support arbitrary params for REST publishes
  • Fix scope leak issue when using the minified version of the library

Ably 1.1 Client Library SDKs release

The 1.1 release, following Semantic Versioning principles, is a backwards compatible release bringing new features and improvements to the library. Full docs here.

Major new features

  • Transient publishing is now supported on channels. Previously, for Realtime client SDKs, when you create a channel and publish a message, the client library would attach to the channel and then publish the message. For use cases where publishing only was needed, this resulted in the Ably service sending all messages to the client as soon as it attached to the channel, even if no subscribe listeners were registered. With 1.1, if you do not attach to a channel, then you can still publish to the channel without the risk that inadvertently the client would also start receiving all message published on that channel.

  • Request method provides access to undocumented, experimental and beta features available in the platform, but not yet available in the SDKs, such as batch publishing. The method has been extended to support all HTTP verbs available. Batch REST publishing is not natively supported by any SDKs yet, however the request method allows access to this experimental API. Batch publishing allows a single REST operation to publish one or more messages to one or more channels in a single operation.

  • Push Notifications are now in General Availability following beta testing and feedback from our customers. There are some backwards compatible changes you should be aware of when upgrading to the 1.1 GA release if using push notifications, specifically in regards to authentication of devices with the Ably service. In the coming weeks, we’ll be sending out an update specifically on push notifications with links to documentation, tutorials, notes on upgrading from the beta release, and summarising all the features now available to all customers. If you want to upgrade before then, get in touch.

Note: iOS and Android are push targets, whilst all other client libraries provide push admin support for registering devices, managing subscriptions, publishing messages etc. We are considering adding web push notification support to our JS library so let us know if you need support for a browser target.

  • Idempotent REST publishing ensures that a failed publish to a network failure, or any other failure, can safely be retried without worrying that a message may be published more than once. In effect, we’re adding exactly-once semantics to our REST publishes over a protocol (HTTP) that has historically had shortcomings at a protocol level in regards to idempotent operations. Idempotent publishing is supported in all 1.1 client libraries. However, it's not enabled with this release as we're not ready to release it into the global cluster just yet. We’ll be enabling it server-side in the coming weeks. Once we do, we’ll let you know.

Other new features in 1.1

  • A client ID specified in the ClientOptions, when supported by the authentication scheme used, is now more consistently applied to all operations including REST publishes, or Realtime connections. See documentation on Ably identified clients.

  • The client library is now responsible for ensuring any channels it is present on are stored for the lifetime of the client instance, and if the connection is disconnected for an extended period of time (longer than the connection state TTL of two minutes), the client library will automatically re-enter into the channels it was previously present on before the connection was closed.

  • In some client libraries, support for the new Ably DSX stats have been added. DSX allows businesses to exchange realtime data assuming either a producer or consumer role, without having to deal with the complexities of protocol interoperability, scale, performance etc. Find out more.

Significant client library-specific updates

  • iOS

    • iOS is now multi-platform, support tvOS and macOS
    • Push GA as a target
  • Android

    • Push GA as a target
  • .NET

    • Major upgrade from 0.8 to 1.1 (we skipped 1.0)
    • Unity experimental support added
    • Wide platform support with .NET 4, .NET Core, Mono, UWP, Xamarin Android & iOS
  • go
    • Major upgrade from 0.8 to 1.1 (we skipped 1.0)
    • For now this applies only to the REST library due to high demand from users heavily reliant on Go for their server-side architecture

Stability and performance

  • More reliable processing of REST operations when a datacenter is unavailable and a client library is using fallback hosts to route around network or datacenter issues. Now, when a fallback host is used and successfully completes an operation, the fallback will be used for 10 minutes before retrying the primary host. Previously every subsequent attempt would try the primary host thus delaying all operations until the datacenter that the primary host routes became available again.

  • Handling of exceptions, including exceptions in callbacks / blocks provided to the library, are handled more gracefully with more information to help with debugging.

  • Improved handling of server-side authentication failures such that a client library will continue to attempt to obtain a new token and leave the connection in the disconnected state instead of moving to the failed (terminal) state.

  • Invalid requests such as publishing messages that are too large fail earlier, thus saving bandwidth for clients and improving the responsiveness of failures in a more deterministic way.

  • The client libraries no longer attempt to recover connection state when they detect, prior to reattempting to connect, that the connection state is no longer available within the Ably service due to the connection state TTL passing. In addition, the client library automatically reattaches all channels that were previously attached once a new connection is established.

  • Bug fix relating to connections that were not successfully resumed and the serial numbering system not being reset. This rarely resulted in lost messages from the client to the Ably service.

  • Improved handling of batched messages in Realtime libraries when a connection is not available, and messages are queued.

  • Various bug fixes in the present set maintained by client libraries subscribing to presence channels relating to fabricated leave messages that are generated by the realtime service when it detects a client has gone away temporarily.

  • Bug fixes in the EventEmitter to ensure mutations to the listeners during an event being emitted has no unexpected affect.

Improved developer UX

Upgrade to continue getting the best out of Ably

There’s some exciting new features in this backwards-compatible 1.1 client library SDKs release. We highly recommend you upgrade to take advantage of the improved APIs, new features and functionality, and fixes and improvements.

Ably Javascript client library release 1.0.21

  • Reinstate 'stop clientId forcing token auth' change (temporarily reverted in 1.0.20)
  • Prioritise a tokenParam over an authParam of the same name
  • Fix behaviour with multiple concurrent pings in-flight
  • Use console.warn (if present) when logging at ERROR level
  • Implement client-side-enforced maxMessageSize limit and bundling constraints
  • Deduce streaming response from lack of content-length header even if no transfer-encoding

Ably javascript client library release 1.0.19

  • Expose rest#setLog method to change log level or handler at runtime
  • Allow jsonp for REST requests even if allowComet is false
  • Expose Rest.Message for node, for consistency with Realtime.Message
  • Add updateOnAttached channel option to force 'update' event even if resumed is true
  • Stop a clientId from forcing token auth (
  • Fix to NPM package creation that was unnecessarily bloating the package size

Ably javascript client library release 1.0.18

Ably Javascript & Node.js release 1.0.17

Client library release:


  • Give presence.subscribe attach callback the same behaviour as channel.subscribe, for consistency (so it calls back once attached rather than only in the event of an attach error) #526
  • Handle empty string response from an authUrl or authCallback as a token error
  • Upgrade ws module to v5 (nodejs only) #525

Note: this release drops support for nodejs versions < 4.5. node v4 versions 4.5 or later are still supported; customers using node v4 are highly encouraged to update to the latest 4.x branch for security reasons

No published changelogs yet.

Surely Ably - simply better realtime will start publishing changelogs very soon.

Check out our other public changelogs: Buffer, Mention, Respond by Buffer, JSFiddle, Olark, Droplr, Piwik Pro, Prott, Ustream, ViralSweep, StartupThreads, Userlike, Unixstickers, Survicate, Envoy, Gmelius, CodeTree