Standard message config for In Out topics: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| 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 = | ||
| Line 15: | Line 9: | ||
<syntaxhighlight lang="JavaScript"> | <syntaxhighlight lang="JavaScript"> | ||
{ | { | ||
topic: {string} | |||
properties:{ | properties:{ | ||
{propertyName}:{ | {propertyName}:{ | ||
| Line 33: | Line 27: | ||
.. | .. | ||
], | ], | ||
allowAdditionalProperties: true|false, //default: true, if false only the specified properties are allowed | allowAdditionalProperties: true|false, //default: true, if false only the specified properties are allowed | ||
} | } | ||
| Line 46: | Line 39: | ||
* Can add to middleware function/s for validating sent messages adheres to this services MsgCfg setting | * 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 | * All messages sent to MsgOut must have a matching MsgCfg value | ||
* 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 55: | Line 48: | ||
= 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) | ||
Revision as of 15:23, 17 April 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
{
topic: {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, 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
},
..
],
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 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)