Standard message config for In Out topics

Overview

All messages sent to In or Out SNS topics have a configuration schema, this is used by the Message Config Manager service that stores every MsgCfg for every service in the project, which can then be used for example by the frontend that sets up user notifications, or Activity Switchboard service.

The MsgCfg could also be used to validate messages being sent/received are formatted correctly.

MsgCfg syntax

• unique key of each msgCfg is the {serviceName}_{topicName}

{
	serviceName: xx
	topicName: yy
	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, only checked when isObject = false
		},
		..
	}
	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 MsgCfg setting
• messages sent to topics can have a matching MsgCfg value, if have can use this to validate the message before sending
• Might need a separate middleware function that processes and validates messages sent to In / Out topics, before processing standard SNS middleware request
• Maybe split In and Out into different middleware functions, Out 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 an In / Out topic's name, dependent 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 dependent 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 topic, eg if topic gets changed or removed we don’t have to remove them from users notifications configs, those configs will simply stop receiving messages (although best to clean up, but we could periodically do that rather than trying to clean up each time there is a change)