top of page
Keet Malin Sugathadasa

Real Time Notification Architectures for Frontend Applications


Providing quick and real time responses to users has become a must, in today's applications where quick response is mostly preferred over persistence. Whenever a certain event is being processed, a notification is what users expect as a confirmation of the event. Earlier it used to be persistent mechanisms like emails, UI updates etc. Users used to log in to their email inboxes and refresh the page to see whether they have received a confirmation on an event processing. But today, emails are only used as a mode of official communication and a persistence mechanism, which users rarely check, on the fly. Today, we see a lot of infrastructures and platforms that provide the capability for applications to integrate real time push notifications into their platforms. The confusing part is to select which platform suits you the most to cater for your use cases.

This blog post describes most of the available real time push notification mechanisms. This includes both open source and proprietary products. This blog will talk about the following "Real time push notification architectures" and provide a comparison on several evaluation criteria.

  1. Socket.io

  2. PubNub

  3. Crossbar.io

  4. RethinkDB

  5. Firebase

  6. AWS Simple Notification Service

  7. Deepstream.io

  8. Pusher

  9. Realtime.co

  10. Fanout.io

  11. Push Technology

  12. Ably

The real-time web is a network, that uses technologies and practices that enable users to receive information as soon as it is published by its authors, rather than requiring that they or their software check a source periodically for updates. The purpose of this document is to evaluate available real-time push notification architectures, which are required in real world applications. The given architectures include both commercial and non-commercial solutions, which have their own pros and cons depending on our requirement.

General Notification Architectures

Initially, let's have a look at the architecture diagrams that are suitable for notification systems in general. The architectures in this document are suitable for any application that requires real time persistent notifications to be delivered to a mobile/web application. There are two ways to implement notification systems in an application.

  1. Polling Mechanism

  2. Push Notification

General Architecture for Polling

This architecture depicts a polling mechanism which polls for messages from a micro-service and retrieves notifications as required.

Pros

  • Application can handle polling times in a flexible manner

  • Simple architecture where inter-component dependencies are less

  • Massive sets of transactions in parallel/partitioned can be handled in ever smaller execution windows

  • Increase in processing power means increase in data sets that can be dealt with.

  • We can get what we want when we want it, via scheduling.

  • Predictive support, predictive failures, predictive model - leading to standardization, and automation.

Cons

  • Requires a Landing Area (in memory storage) for the transformed data sets.

  • Requires massive sets of processing power (for large data)

  • Batch Windows are continually shrinking while data sets are ever growing.

  • Batch Window: The time available for an intensive batch processing operation such as a disk backup.

  • Requires sources be defined beforehand (less flexibility).

  • Overwhelms the front-end, if polling happens in short windows.

General Architecture for Push Notifications

This architecture depicts a push notification mechanism that will push notifications to the front end application where it will be listening for messages.

Pros

  • Instant transaction communication

  • Transaction by Transaction / Guaranteed delivery mechanisms.

  • Guaranteed Ordered mechanisms

  • Mass Distribution, or publish subscribe to those that want it.

  • New sources can come on-line and push out new transactions

  • Feedback on the transaction after the business processes are invoked.

Cons

  • Independent transactions - meaning can't rely on "history", can't rely on "trends"

  • Difficult to establish context

  • Once a transaction is sent - it's gone (unless persisted)

Architecture Comparison

Socket.io

We can implement everything from the scratch on Web Sockets with the socket.io client.

PubNub

PubNub is a global Data Stream Network (DSN) and real-time infrastructure-as-a-service (IaaS) company based in San Francisco, California. The company makes products for software and hardware developers to build real-time web, mobile and Internet of Things (IoT) applications.

Crossbar.io

Crossbar.io is an open source networking platform for distributed and microservice applications. It implements the open Web Application Messaging Protocol (WAMP), is feature-rich, scalable, robust and secure.

RethinkDB

RethinkDB is a free and open-source, distributed document-oriented database, originally created by the company of the same name. The database stores JSON documents with dynamic schemas and is designed to facilitate pushing real-time updates for query results to applications.

If you are interested in implementing your own notification platform via RethinkDB, have a look at this blog.

Given below is the Architecture diagram of a system that is using RethinkDB as a notification platform. It is followed by an evaluation to help the reader understand the difference with other models.

Firebase

Firebase Cloud Messaging (FCM) provides a reliable and battery-efficient connection between your server and devices that allows you to deliver and receive messages and notifications on iOS, Android, and the web at no cost.

Given below is the architecture diagram for Firebase aided notification platform which is followed by an evaluation.

AWS Simple Notification Service

Amazon Simple Notification Service (SNS) is a flexible, fully managed pub/sub messaging and mobile notifications service for coordinating the delivery of messages to subscribing endpoints and clients.

Deepstream.io

Deepstream is an open source server inspired by concepts behind financial trading technology. It allows clients and backend services to sync data, send messages and make RPCs at very high speed and scale.

Pusher

Pusher Channels provides real-time communication between servers, apps and devices. Pusher Channels is used for notifications, chat, gaming, web-page updates, IoT, and many other systems requiring real-time communication.

Realtime.co

Real-time Messaging is a cloud-based message broker. Enabling developers to build cross-platform apps that require real-time communication between devices.

Fanout.io

Fanout Cloud makes it easy to build and scale real-time/evented APIs. Such APIs are useful for pushing data instantly to browsers, mobile apps, servers, and other devices. The service is a cross between a reverse proxy and a message broker. This unique design lets you delegate away the complexity and load of real-time data push while leveraging your API stack for business logic.

Push Technology

Push Technology is trusted by leading brands worldwide to manage their web, mobile, and IoT application data. Every business developing next-generation applications, and working on digital transformation initiatives, requires advanced technology to streamline Internet communications to and from back-end systems and applications—reliably, globally, and at scale and speed.

Ably

Ably can deliver native push notifications to devices using, among others, Apple’s Push Notification service and Google’s Cloud Messaging service. Native push notifications, unlike Ably’s channel-based pub/sub messaging, do not require the device to maintain a connection to Ably as the underlying platform or OS is responsible for maintaining its own battery efficient transport to receive push notifications. Therefore, native push notifications are commonly used to display visual notifications to users or launch a background process for an app in a battery efficient manner.

 

3,409 views1 comment
bottom of page