Standard message config for In Out topics

Overview

All messages sent to MsgIn or MsgOut SNS queues have a hardcoded configuration, this is used by the Message Config Manager service which stores every MsgCfg for every service in the project, which can then be used for example by client that sets up user notifications, or Activity Switchboard service.

This configuration can also be used to validate messages being sent are formatted correctly.

MsgCfg syntax

{
	msgTag: {string}	
	properties:{
		{propertyName}:{
			required: true|false, //default: true
			stringified: true|false, //default: false
			isObject: true|false, //default: false, if is an object will look for child properties
			properties: // if is set to isObject: true, nest levels using properties
			activityTrigger: true|false, //default: false, whether can be used as a trigger in Activity Switchboard service
		},
		..
	}
	messageAttributes[
		{name}: {
			required: true|false, //default: true
			activityTrigger: true|false, //default: false, whether can be used as a trigger in Activity Switchboard service
		},
		..
	],
	activitySwitchboard: true|false, //default: false, if set to false Activity Switchboard service will not setup a subscription to receive these messages
	allowAdditionalProperties: true|false, //default: true, if false only the specified properties are allowed
}

Location of MsgCfg file

...

Validation of outgoing messages

• Can add to middleware function/s for validating sent messages adheres to this services MsgCfg setting
• All messages sent to MsgOut must have a matching MsgCfg value
• Might need a separate middleware function that processes and validates messages sent to MsgIn / MsgOut, before processing standard SNS middleware request
• Maybe split MsgIn and MsgOut into different middleware functions, MsgOut can hardcode topic sent to

Validation of incoming messages

• Triggered Lambda Handler could pull the sending services MsgCfg to use as validation structure for received message, can skip for now and hand write validation schema in receiving Lambda

Notes

• If developers change the msgTag, dependant services will likely break (eg pointers in notification service will no longer match), must be careful doing this
• If update other config settings, eg expected/optional parameters, will need to get dependant services to re-build, eg Activity Switchboard service will need to rebuild its local database MsgCfg's
• Notification Manager service does not need to link to a real MsgTag, eg if MsgTag gets changed or removed we don’t have to remove them from users notifications configs, those configs will simply stop filtering accurately (although best to clean up, but we could periodically do that rather than trying to clean up each time there is a change)