Push notifications are an important part of modern applications, whether you’re targeting desktop or mobile, or even the web. But as your applications grow, you need a service that can scale with them, delivering messages with minimal latency no matter how many users you have and no matter where your services are hosted.
While it’s possible to construct your own notification service, routing messages to the appropriate targets and users, scaling remains a problem, as well as supporting users across the world. Notifications need to be delivered asynchronously, allowing you to treat them as a fire-and-forget option, triggering a notification when it occurs with the assumption that it will be delivered in a timely fashion.
There’s an additional issue: There are many different kinds of notification, and an application may need to support several of them at the same time. Some might be broadcast messages for all users, while others target individuals and groups. That’s only part of the problem. You also have to deal with multiple APIs and authentication and authorization schema. The result can be a complex infrastructure, with significant management overhead and costs to match.
What’s needed is a configurable service that works with various notification providers’ platforms, and that can support many different use cases and message types, without adding complexity to your code. Working with such a service should give you one API for all messages, and one place to manage your users, groups, registered devices, and access keys.
Cross-platform notifications from the cloud
Azure Notification Hubs are one option, a service agnostic way of delivering messages to any platform without tying you to one application platform. That ensures code portability, so your application can call an Azure Notification Hub from Google Cloud or AWS or on premises, as well as from Azure. Microsoft’s messaging architecture, which Azure Notification Hubs are a big part of, builds on lessons learned when running the popular MSN Messenger service, and includes some of the same services.
Azure Notification Hubs remove a big piece of the management overhead associated with DIY messaging services. Instead of having to manage all aspects of the messaging stack, you can hand over the key functionality to Azure. That doesn’t require giving up your relationship with your users. Applications running on their devices still need to register for notifications with the appropriate service, and they still need to deliver that registration and any keys to your back end. But when you deliver the message and the key to Azure Notification Hub, it handles structuring the message and delivering it to the target notification service, which then uses the native delivery tools to push messages to your users’ devices.
Azure Notification Hubs support most common delivery scenarios, from working with individual devices and users to targeting users in a specific area, and even provide tools for personalization. After all, the platform needs to support the ways you want to communicate with users, without locking you into a single design pattern. This means the same service can push 2FA codes to a specific user on a specific device, or let users know of upcoming downtime on all their devices. The option to add geofences to messages is a useful one, too, allowing weather apps to warn users in the path of a storm of possible dangerous conditions.
Setting up an Azure Notification Hub
Getting started with the service is relatively simple. You first need to create a Notification Hub on Azure. As per usual with Azure, there are multiple ways to do this. You can use the Azure Portal, use the Azure CLI, author and deploy an Azure Resource Manager template, or use configuration-as-code via Bicep. There’s also the option of working with third-party tools like Pulumi or Terraform, which drive the Azure API to create and deploy a service.
If you’re experimenting with Azure Notification Hubs, producing a one-off, then the Azure Portal is likely to be your best option. The other methods let you create scripts that can be used to automate deployments across regions or geographies, or as part of an immutable infrastructure that’s delivered as part of an application build.
Setting up a Notification Hub via the Azure Portal is much like working with any other Azure service. Start by assigning your new hub to a subscription and a resource group, then add it to a namespace, choose a location, and use availability groups if you want to increase service reliability. There’s additionally a useful disaster recovery option that will automatically spin up your service in another region in the event of a failure. This allows your application to continue operating in the event of an Azure outage.
You can now create your hub. Wait for Azure to complete the process before configuring it to work with your choice of platform services. Again, you get your choice of configuration approaches, via the Azure Portal or Azure CLI. Once your Notification Hub is ready to use, click through to it in your Azure Portal.
Each target service requires separate configuration, using authentication methods configured when registering for that service, So, for example, if you’re setting up Apple’s push notifications, you need to upload the certificate shared with Apple or the token details generated as part of your registration. Similarly, you need the API key for Google’s Firebase service and the security key for the Windows Notification Service.
Using Azure-powered notifications in client apps
You’re now ready to add push notification support in your code. This will require the appropriate authentication tokens and certificates for your device platform. Apps will need to be registered with the service, so use its tools to do this. This is where you get the authentication tokens needed for Azure Notification Hubs. You can now create a hub to work with this service, which will generate the connection strings that are used by your back-end application to deliver messages.
Client apps will need to register devices with Azure, using the device-specific Azure Notification Hubs SDKs, which are available on GitHub. You will need to add the hub name and the connection string to your code, along with boilerplate code that sends the device ID to Azure. Microsoft provides tooling to send test notification in the Azure Portal. This allows you to ensure that your device code is working correctly. Back-end code can use either the service REST APIs or a .NET SDK to send messages to devices, as well as managing device registrations. Messages are received and displayed using device-native tooling, so you only need to write code to register apps and devices and to send messages via hubs.
One important point to note is that Android is migrating to a new messaging API, and as a result, existing Azure Notification Hub applications will need to be updated by June 2024. There is some housekeeping required, running new and old notification services in parallel while moving device IDs from the old service APIs to the new. You will need to update client-side code so that it registers with the updated service.
A cross-platform notification service
Using Azure Notification Hubs isn’t too expensive, with volume-based pricing and three different tiers. A free tier is suitable for development purposes, supporting up to 500 devices and one million notification pushes per month. At the high end, there’s a $200 per month standard service, with support for significantly more pushes (and the option to pay $2.50 per million once you exceed 100 million pushes per month). The standard service includes the ability to schedule notifications, as well as offering detailed telemetry.
By providing a cross-platform notification service, Microsoft makes it easier to build and operate multi-device applications and services. As long as you keep within service limitations, one push service should support all your users. You only need to write device-specific handlers when you want to take advantage of client-specific features.