Translations:NPM module - izara-middleware/75/en: Difference between revisions

From Izara Wiki
Jump to navigation Jump to search
(Importing a new version from external source)
 
(No difference)

Latest revision as of 04:33, 4 October 2022

Information about message (contribute)
This message has no documentation. If you know where or how this message is used, you can help other translators by adding documentation to this message.
Message definition (NPM module - izara-middleware)
* Is a list of services waiting for a response within a single process
* A new entry is added to the requestServices list manually by main logic when a service will be wanting a response, some intermediary Lambda's may not need to be added to the list
* Functions as a LIFO list
* Best type would be an array where we can use push/pop methods, not sure correlation ids middleware can handle this, might need to stringify then parse array
* A service can add a different service's Lambda to the list, eg one service might add a different service to receive the response
* A service could add multiple entries to the list
* When a message is added to a topic, middleware checks to see if there are any entries in the requestServices correlation id, if there are it adds a ''requestService'' message attribute to the message, this can be filtered by subsciptions so only that service receives the message
* Only when adding to an Out queue, because if a Lambda adds eg to an In queue it is not considered an activity that is passing a result back to another service.
* We could have a special wrapper function for adding messages to a services Out queue that does this, rather than coding it into the SNS service request code
* When the Out message adds the requestService to message attributes, also pop it off the requestServices correlation id that gets passed on 
* Maybe can remove from Dynamo __context__ field, but if we ever use Dynamo Streams will probably want to keep it
  • Is a list of services waiting for a response within a single process
  • A new entry is added to the requestServices list manually by main logic when a service will be wanting a response, some intermediary Lambda's may not need to be added to the list
  • Functions as a LIFO list
  • Best type would be an array where we can use push/pop methods, not sure correlation ids middleware can handle this, might need to stringify then parse array
  • A service can add a different service's Lambda to the list, eg one service might add a different service to receive the response
  • A service could add multiple entries to the list
  • When a message is added to a topic, middleware checks to see if there are any entries in the requestServices correlation id, if there are it adds a requestService message attribute to the message, this can be filtered by subsciptions so only that service receives the message
  • Only when adding to an Out queue, because if a Lambda adds eg to an In queue it is not considered an activity that is passing a result back to another service.
  • We could have a special wrapper function for adding messages to a services Out queue that does this, rather than coding it into the SNS service request code
  • When the Out message adds the requestService to message attributes, also pop it off the requestServices correlation id that gets passed on
  • Maybe can remove from Dynamo __context__ field, but if we ever use Dynamo Streams will probably want to keep it