Skip to content

Push Notifications

Jump to bottom
Jon Park edited this page Aug 7, 2018 · 3 revisions

Requirement being considered: As a user I should be able to receive push notification on my device (Android / IOS / desktop web app) from Mashling gateway.

Design thoughts

Solution using google's Firebase Cloud Messaging (FCM) platform

Firebase Cloud Messaging (FCM) is a cross-platform messaging solution that lets you reliably deliver messages at no cost. Solution implementation includes 2 main components:

  • Application server - A trusted server on which to build, target and send messages.
  • Client application - An Android, iOS, or web (JavaScript) client application that receives messages.

Below is the pictorial representation of the overall architecture.

  • STEP 1: Client application registers itself with FCM.
  • STEP 2: FCM generates registration id for the client.
  • STEP 3: Client sends registration id to App Server.
  • STEP 4: When app server wants to send push notification, it sends a request (message + registration id) to FCM.
  • STEP 5: FCM identifies the client using registration id and sends push message to it.
  • STEP 6: Client shows notification to user.

Push Notifications Solution for Mashling

Push notification solution for Mashling can be realised by leveraging google's Firebase Cloud Messaging (FCM) platform. It includes below mentioned components:

  • FCM - google's push messaging platform
  • App Server - logic to create and submit push message with FCM
  • Client Application - to receive push notification
  • Mashling gateway - Contains custom trigger/activity/flow to communicate with App Server to initiate push notification

Various design options are explored based on how server component for FCM is implemented, how it is deployed and how client device token exchange is managed. Exlpored design options are mentioned in detail as below.

Design Option 1

This option involves dedicated App Server for FCM.

Pictorial representation:

This option requires dedicated server environment for App Server.

Design Option 2

This option uses google's cloud function for FCM.

Pictorial representation:

Since this option uses google's cloud function (Server less), dedicated server is not required.

Design Option 3

This option uses 3rd party push notification aggregator - OneSignal.com

Pictorial representation:

Since this option uses OneSignal server API & client SDK, user not required to implement App Server logic, device token exchange mechanism between client ↔ FCM ↔ Server.

Note: Currently it is a free service that supports unlimited devices and notifications. OneSignal makes money by selling data to advertisers and research companies.

Design Option 4

This option without having server component.

Pictorial representation:

Since there is no dedicated App Server, device token exchange has to be done manually.

Note: This option can be considered only for POC and same is not recommended for production use because of below reasons:

  • gateway contains server functionality which is not a good practice.
  • manual device token exchange & no token refresh mechanism.

Conclusion

After exploring above mentioned options, Option 2 can be considered for the following reasons:

  • It doesn't require any dedicated server environment, instead it uses cloud function.
  • It doesn't depend on 3rd party platform (like OneSignal).
  • It is open source user friendly. For instance user can easily get started with cloud function implementation using google's rich documentation & free tier cloud infrastructure.

Next Steps

Develop a recipe which demonstrates how Mashling gateway can trigger push notification by leveraging google's cloud function & FCM (Option 2). Recipe solution may include:

  • Android / Web (Desktop) application to receive push notification
  • Instructions to setup & configure FCM
  • Cloud function implementation & deployment steps
  • Mashling gateway (custom activity / flow to invoke cloud function + trigger condition to initiate push notification)
Clone this wiki locally