NPM module - izara-middleware

Overview

Code that is shared by all services, including middleware code that executes at the beginning and end of each Lambda function and supporting code.

Middleware

The middleware that executes at the beginning and end of Lambda functions uses the Middy middleware module.

Middleware components

The below middleware components are executed in the below order:

captureCorrelationIds

..

integrationTests

Checks correlation ids for intTest-tag which should only exist if the request was initiated by the Integration Testing service.

If is part of an integration test then send a message to MsgOut queue with the event object.

sampleLogging

...

stopInfiniteLoop

...

logTimeout

...

httpHeaderNormalizer

...

jsonParseBody

...

urlEncodeBodyParser

...

validator

...

flattenRequest

...

serviceStack

Adds an element to serviceStack correlation id

integrationTests

All services will have an SNS queue deployed named MsgOut, this middleware adds a message to this queue when the middleware's LOG_LEVEL is set to DEBUG at the start of the request with the functions received request properties and at the end of the function with the final response formatted in a standard way for Integration Testing to process.

Service requests

The middleware module includes wrapped objects that manage requests sent to other AWS services, this allows the middleware to add or adjust the request in a standard way, passing on values across the lifetime of a multi-resource action.

Services

The following services are supported:

DynamoDB

..

Firehose

..

Http (API Gateway)

..

Kinesis

..

Lambda

..

SNS

..

SQS

..

Step Functions

..

Other libraries

msgOutConfig

=== Standardize and validate messages to msgOut queue

• When sending a message to the services msgOut queue use a library function to do this, ensuring that all messages to the queue have a configuration entry in Standard MsgIn MsgOut message config
• Each msgOut message has a messageTag which matches a config entry

Send msgOut config to Message Config Manager service

• Lambda function that sends all current message configs to Message Config Manager
• Finds the Message Config Manager endpoint from an entry in Config table

Special correlation ids

requestServices

• 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 wants 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 msgOut queue, 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 the msgOut queue, because if a Lambda adds eg to a msgIn 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 msgOut queue that does this, rather than coding it into the SNS service request code
• When the msgOut 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

serviceStack

• Is a list of all calling services (and Lambdas?) up to this point, from the first entry point that triggered the workflow
• Gets passed on and added to automatically in middleware and helper/client code
• Handle as an array, might need to stringify when saving as a correlation id
• If workflow passes back to calling services we do not pop/remove from this list, just keep adding
• Maybe can remove from Dynamo __context__ field, but if we ever use Dynamo Streams will probably want to keep it