Notification Module overview
The Notification Module provides developers with a pre-made but extensible solution to send user notifications by using templates or free-text messages, across the most common notification channels (email, sms, push, voice, whatsapp).
This software component built with a microservice architecture sends messages through a series of communication channels. It exposes a synchronous HTTP REST and an asynchronous Kafka-based API to send messages and fetch notification info. The internal communication between different microservices is implemented with synchronous HTTP REST interfaces.
The module is packaged as a [Mia-Platform Application][mia-application], enabling developers to configure everything in just a few steps and have all the services up and running.
It installs the Notification Manager Service and its dependencies, enabling all communication channels by default. This is the list of the installed microservices:
| Component | Version |
|---|---|
| Notification Manager | 2.4.0 |
| SMS Service | 1.2.0 |
| Email Service | 3.3.0 |
| Files Service | 2.10.1 |
| Timer Service | 2.1.3 |
| CRUD Service | 7.1.0 |
| API Gateway | 5.0.2 |
Module Architecture
This is an high level overview of the NM:
Overview of Notification Module architecture, based on an Http REST interface to send messages through various communication channels.
Incoming requests are redirected to the Notification Manager, which is the core component of the whole module and implements the business logic of sending messages. It is responsible for validating external requests and send the correct messages to the correct users.
The Messages are sent using external providers, that can be called directly by the Notification Manager or by the two microservices SMS Service and Mail Service. The supported communication channels are:
Email attachments are handled by the Files Service, which supports the most adopted file system providers.
Messages can also be scheduled in the future using the Timer Service.
All data, with the exception of users, is handled by the CRUD Service, which is a thin layer API built over a MongoDB database. These are the database collections:
Details about the collections schema are in the Notification Manager configuration documentation.
Users data can be requested from an external API, which must expose an compatible with the CRUD Service and the data model described here.