Power your Web/PWA app with Instant Messaging & Alerts

 Adding a real-time messaging & alert system to your app is the key and utmost requirement in today’s world.

This article outlines an end-to-end architecture. We’ll illustrate with Azure services, but you can easily adapt the approach using your preferred open-source or cloud alternatives.

Use Case: We need to implement a real-time alert delivery mechanism for our PWA web application (running on both browser and mobile platforms). This system must ensure that all alerts generated by various backend systems are reliably and instantly delivered to users without any data loss.

Solution Design

To ensure no alerts are missed, we can indeed break down the problem into these two key areas:

1. Real-time Delivery to Online Users (Web/Mobile): The first challenge is to guarantee immediate delivery of alerts to users who are currently active and connected to the web or mobile application.
2. Reliable Delivery to Offline Users (Web/Mobile): The second critical aspect is ensuring alert delivery to users who are not currently active or connected to the web or mobile application.

To address the requirement of real-time delivery to online users, we’ll establish active WebSocket connections. These connections will enable immediate pushing of messages to the application, which can then be displayed through notification modules like toast messages or bell alerts to effectively capture user attention upon arrival.
To achieve this real-time message pushing via WebSockets, we will utilize the Azure Web PubSub service. You can use your preferred open-source or cloud alternatives.

To handle message delivery for offline users, we’ll implement a persistence mechanism. Alerts will be stored in a database, allowing the application to retrieve and display them when the user comes back online (pull mechanism). For mobile users specifically, we will also leverage Azure Notification Hub in conjunction with Firebase Cloud Messaging (FCM) to directly push the alerts to their devices.

To guarantee no alert loss due to technical issues, we’ll implement a message queue service (like Azure Service Bus or an equivalent). An Azure Function will subscribe to this queue, ensuring reliable processing of each message. This separate function for message handling enhances the service’s scalability and avoids dependencies on our API services.

Here is the complete architecture diagram for the solution.

The left side of the diagram shows various alert producers (including potentially our .NET API). To guarantee delivery, all generated alerts are first routed to Azure Service Bus. From there, upon message receipt, a process is initiated to ensure:
1. Persistence in the database for offline user access upon their return online.
2. Real-time delivery to online users via Azure Web PubSub.
3. Delivery as mobile push notifications through Azure Notification Hub.

To deliver messages to users when they come online, the alerts saved in the database will be served via your .NET Core API. This pull mechanism is employed by the web application only upon its initial load. Subsequently, all real-time message delivery is guaranteed through the Azure Web PubSub service. Because the messages are stored persistently in the database, we can implement features like read/unread status and user-initiated message deletion.

That wraps up this article! I hope you found the information valuable. If you’re interested in staying updated with similar content, don’t forget to follow. Thanks for reading, and happy coding!