Standard message config for In Out topics: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
(10 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
= Overview = | = Overview = | ||
All messages sent to | All messages sent to In or Out SNS topics have a configuration schema, this is used by the [[Service - Message Config Manager|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 [[Service - Activity Switchboard|Activity Switchboard]] service. | ||
The MsgCfg could also be used to validate messages being sent/received are formatted correctly. | |||
= MsgCfg syntax = | = MsgCfg syntax = | ||
* unique key of each msgCfg is the {serviceName}_{topicName} | |||
<syntaxhighlight lang="JavaScript"> | <syntaxhighlight lang="JavaScript"> | ||
{ | { | ||
serviceName: xx | |||
topicName: yy | |||
properties:{ | properties:{ | ||
{propertyName}:{ | {propertyName}:{ | ||
Line 16: | Line 19: | ||
isObject: true|false, //default: false, if is an object will look for child properties | 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 | 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 | activityTrigger: true|false, //default: false, whether can be used as a trigger in Activity Switchboard service, only checked when isObject = false | ||
}, | }, | ||
.. | .. | ||
Line 38: | Line 41: | ||
= Validation of outgoing messages = | = Validation of outgoing messages = | ||
* Can add to middleware function/s for validating sent messages adheres to | * 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 | * Might need a separate middleware function that processes and validates messages sent to In / Out topics, before processing standard SNS middleware request | ||
* Maybe split | * Maybe split In and Out into different middleware functions, Out can hardcode topic sent to | ||
= Validation of incoming messages = | = Validation of incoming messages = | ||
Line 49: | Line 52: | ||
= Notes = | = Notes = | ||
* If developers change | * 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 | * If update other config settings, eg expected/optional parameters, will need to get dependent services to re-build, eg [[Service - Activity Switchboard|Activity Switchboard]] service will need to rebuild its local database MsgCfg's | ||
* [[Service - Notification Manager|Notification Manager]] service does not need to link to a real | * [[Service - Notification Manager|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) |
Latest revision as of 13:59, 10 May 2021
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)