Introduction to Notify Module

Notify Module

Introduction

Notify module is a core system module that handles all processes required for sending notifications from the system. Before we dig into Notify module, let’s define a few critical terms we will use throughout the documentation.

  • Module: Any entity in the system which may request to send notifications to users on different events. E.g., ticket, task, etc.
  • Module authors: Developers writing the implementation of different modules.
  • Channel: Platform or medium on which the system will send the notifications. E.g., Email, SMS, Facebook, etc.
  • Channel authors: Developers writing the implementation for integrating different platforms.

Notify module provides an easy and consistent way for module authors and channel authors to communicate to send notifications throughout the system. Notify acts as an intermediate module between modules and channels that bridges the gap between them and reduces their dependency on each other.

Objective

To understand the objective of Notify, we have first to understand the underlying problems with the current implementation of the notifications. Let’s consider two cases.

Case 1: Add a new notification for adding a unique asset in the ServiceDesk module

Developers will first have to implement adding a new asset to the system. Then worry about required templates, settings, and handling notifications based on preferred settings.

Additionally, module authors must communicate with channel authors about the new notifications. They will also have to consider how new channels can send this notification in the future.

Case 2: Add a new notification channel for sending notifications via Slack

Developers will have to implement integration for Slack using slack APIs. Then they must ensure all modules that send notifications to update their information to accommodate sending messages via Slack.

Additionally, channel authors must communicate with module authors, asking them to implement changes for the Slack channel and consider adding new notifications in the system.

Since there is no defined contract between modules and channels, developers have to break their heads on making changes throughout the system to add new notifications and media.

Notify module targets to create a contract between modules and channels to solve the problems mentioned below

  1. Let module and channel authors focus on the critical work required for implementation rather than making changes throughout the system.
  2. Reduce dependency of module authors and channel authors on each other.
  3. Reduce implementation efforts by handling alert settings and templates and processing notifications on channels based on settings.
  4. Let developers quickly add notifications on different modules or add new channels for sending notifications.
  5. Handle changes required for existing notification modules and channels while adding new ones.

What does it do, and how?

At the functional level Notify module does the following things

  • Handle notification alert settings. Let users activate/deactivate notifications for different events for different receivers and different channels.
  • Handle notification templates for different channels. Let users create and update the content of notifications for different channels.
  • Process sending notifications for preferred settings with preferred template content on the channels.

Notify module can do the above actions and behave as an intermediate module between modules and channels by defining specific contracts. If all module and channel authors follow these contracts initially, they can reduce their efforts and allow Notify to process the notifications. These contracts for modules and channels are as below.

For Modules:

  • When adding new notifications, they need to inform initially about the templates draft, allowed notification receivers, restriction of channels, etc. Using this information, notify can handle alert settings and determine which template to use for notification and which person will receive the message.
  • All modules should dispatch an event with the same payload so that Notify can listen to the events and process the notifications according to the system’s settings.

All modules are required to fire the event with the same structures payload; notify can easily accommodate new notifications for new modules.

For Channels

  • When adding new channels, they need to inform initially about the type of template they support, long or short.
  • After Notify processes the notify event, it fires the notification to the channel event with the same structured payload, which all channels can listen to and process further to send messages to their integrated platform.

 

Note: You can process the notification events in the background using queues.

php artisan queue:work <driver_name> --queue=queue1,queue2,...queueN

Developers can provide different queue names to process notifications with other priorities. Available queue names

  • high_priority_notify: for sending priority notifications
  • notify: Default

Recommended queue command for processing notifications in the background

php artisan queue:work redis --queue=high_priority_notify,notify

 

Summary

Notify module provides a contract for modules and channels. Authors and channel authors need to follow these contracts to add new notifications or channels in the system module. Notify module requires initial information from module and channel authors to provide users with the functionality to update notification-related settings.

All modules must dispatch the event with a predefined payload that Notify can process. After processing the event, Notify will fire multiple events for different channels with a predefined payload. All channels can listen to these events and process them further to send notifications to the platform they integrate into the system.

Hence notify allows developers to easily add notifications/channels in the system and focus on the implementation.