Ed, for extending the FCM, maybe another dev can do the job. I will write a microservice in go for the scope of digital-ui frontend, so in future we will have to care a lot about that frontend. Some requirements: - A notification can be a: 1. an email message 2. a whatsapp message 3. a sms message - A notification is created through an api (POST) - A notification cannot be updated. - A notification cannot be deleted. - A client should be authenticated. - The registration token is generated by a command line tool. No automatic registration endpoint to cut complexity. - The api should async api in order to scale using amazon sqs / azure queue since we don't want to maintain a queue system. - every notification should be logged. - it should be possible to check the state of a notification state so the api should expose a notification endpoint. - A client can enforce notification back in case of an email.
This will lead to two endpoints: - sendNotificationAsync(message: Notification) - getNotificationStatus(): NotificationStatus And three type of messages: *- EmailMessageNotification* *- WSAMessageNotification* *- SMSMessage Notification* *- NotificationStatus* Possible Notification Status: - Pending - Refused - Delivered (success status) Then we have : - NotificationProvider interface - deliver(message: Notification): used by the queue receiver Client working flow (happy path - high level): 1. The client create the appropriate message for notification including in the headers JWT credentials (Bearer Authentication) 2. The client discovers the NotificationService (it can be hardcoded or discovered by eureka). We make it hard coded for now. 3. Send a POST message to sendNotificationAsync 4. The client checks notification status using a timer until it is refused or delivered 5. If delivered with success the UI sends a toast notification to the user. Service workflow (happy path - high level) 1. The service register himself to the SQS queue as sender 2. The service launches a thread working (goroutine) as a receiver. 2. The service receive the message 3. The service authenticates the message through the identity provider (identity). Not yet clear how JWT works on fineract. 4. Sends the pending state to the client 5. The server decodes the message and if it is correct and puts the message in the SQS queue. 6. The receiver gets the message and delivers it to the Notification provider, if it is successful the state becomes delivered. Any comments? I need a part-time week to implement it and test it. As a notification provider i would use Twilio. Outlook/Gmail and normal smtp if you have any suggestion are more then welcome. BR, Giorgio
