Evaluating push notification publishing options based on use-cases

Ably's Push Notifications service offers various options to publish push notifications to devices and also subscribe to those notifications. This article aims to de-mystify all those options so you can choose the one that suits your app the best.


Ably's Push Notifications system is primarily designed to be a Pub/Sub system that lets you deliver notifications to multiple recipients with a single publish. Just like our regular Pub/Sub system used with channels, any interested parties can make a push subscription to a push-enabled channel, and any notifications published on that channel are fanned-out to all its subscribers. Other than this, Ably also allows you to publish notifications directly to a device identified by various device or user credentials, without needing to make use of realtime channels. Both of these methods are further described below.


But, before diving in further, here are a few quick things you should know about Push Notifications in case you missed them out in the documentation:


a) Push Notifications can only be delivered to devices that are registered with Apple Push Notifications Service (APNs) for iOS devices or Firebase Cloud Messaging (FCM) for Android devices. This can be done easily via Ably or directly with those services.


b) After the registration with APNs or FCM is successful, you'll have access to certain device credentials like device ID and deviceToken (for iOS) or registrationToken (for Android) that uniquely identify your devices.


c) Ably allows you to assign a unique clientId to identify your users. This can be done at the time of authenticating your clients, either on the server-side using an auth-server or simply on the client-side when as part of a token request to your auth-server, or simply as part of client options in case of basic auth. It is possible that the same user (identified by a clientId) is using your app on different devices.


Now that you are up to speed on the concepts, let's dive into different ways of publishing push notifications and how you can choose between them.


1. Publishing push notifications via realtime channels


Subscription to Push Notifications (via channels) can be done in two ways: 

1) You can subscribe to the channel using deviceId so that the device receives notifications without there being any association with a specific user identified by a clientId or 

2) You can subscribe to the channel using clientId so that that particular user receives notifications irrespective of what device they are on (assuming that those devices were already registered with APNs or FCM).


2. Publishing push notifications directly using device/user credentials


In addition to the channel-based pub/sub style push notifications described above, Ably also allows you to directly publish a notification using certain recipient parameters. These recipient details are available after a device has either successfully registered with Ably, and/or with APNs/ FCM.


Again, direct publishing can be done in three ways - using the device's deviceId, using the clientId of the user using a registered device or using a deviceToken or registrationToken (for iOS and Android respectively). 


3. Choosing between direct-publish and channel-publish


With direct publishing, you essentially opt-out of using Ably's primary Pub/Sub mechanism to publish notifications to any number of subscribers and instead publish to specific (identified) recipients. If your use-case allows you to identify the clients/devices to which to send notifications to, you can use the direct-publishing mechanism. But if your use-case works best with regular realtime channels, you can simply use the channel-based publishing.


Further, if you are registering your devices with APNs/FCM by yourself without making use of an Ably SDK, meaning, you have the required deviceToken and registrationToken details, you can again use direct publishing (using native recipient details) to publish to those devices without needing to use Ably SDKs on the client-side at all.


Hope this article helps you decide which strategy goes best with your use-case. But if you are still having difficulties implementing push, feel free to drop us a line and we'll be happy to help you out :)