Challenge Overview
Challenge Overview
Technology stack
-
AWS Lambda
-
AWS API Gateway
-
DynamoDB
-
AWS SNS
Project background
We built several bots over AWS Lambdas for communication from/to Topcoder Slack, Client Slack, and Client MS Teams. The current architecture is as below.
The tech stacks are
-
AWS Lambda + Serverless tool
-
DynamoDB
-
AWS SNS
The source code of Lambdas are
-
Central TC Lambda: https://github.com/topcoder-platform/Topbot/tree/central-lambda
-
Slack Lambda: https://github.com/topcoder-platform/slack-bot-processor
-
Teams Lambda: https://github.com/topcoder-platform/MS-Teams-bot-processor/tree/feature/teams-lambda
Follow the README of each Lambda for understanding detailed steps of deployment and interaction between bots, slacks and Teams.
General requirements
1. Move Dynamodb table creation logic (if the table doesn’t exist) to serverless.yml.
Currently, the table creation is implemented in the NodeJS layer, see
-
Central TC Lambda: https://github.com/topcoder-platform/Topbot/blob/central-lambda/src/common/dbHelper.js#L25
-
Slack Lambda: https://github.com/topcoder-platform/slack-bot-processor/blob/master/src/common/dbHelper.js#L25
-
Teams Lambda: https://github.com/topcoder-platform/MS-Teams-bot-processor/blob/feature/teams-lambda/src/common/dbHelper.js#L25
The NodeJS layer has limitations, for example, dynamodb.listTables()only returns 100 tables at maximum. If there are more than 100 tables in the DB, then it has issues.
Hence, we are asking you to move the table creation (if the table doesn’t exist) logic to serverless.yml. Here is a reference: https://serverless-stack.com/chapters/create-a-dynamodb-table.html
2. Creating required IAM roles with required permission for SNS topic to publish message to lambda functions via serverless.yml
While deploying Lambdas on AWS, it requires IAM roles with required permission for SNS topics to publish messages to lambda functions. These should be configured in serverless.yml so that we don’t need to create these roles manually.
3. Add proper logging at enter/exit of Lambda functions
For each Lambda function, add proper logging at enter/exit.
4. Add proper error handling wherever needed
You need to dive into the code and add proper error handling wherever needed. Error handling can be simply error logging so that in case the error occurs, we can simply diagnose where the error is.
5. Remove hard-coded service URL for Teams Lambda
In Teams Lambda, the Teams bot service URL is hardcoded as India (in) area, see: https://github.com/topcoder-platform/MS-Teams-bot-processor/blob/feature/teams-lambda/src/common/helper.js#L47
It might cause issues if the Teams bot was installed in other areas. For example, in other areas, the service URL should be changed as
-
Asia-Pacific: https://smba.trafficmanager.net/apac/
-
North, Central, and South America: https://smba.trafficmanager.net/amer/
One suggestion is (Just a suggestion, not mandatory requirement): we would need to store the serviceURL in our DB when the request was initiated from the client, as the very first event of the client contains that service URL field and that could be used later for further interactions. For example, from here we can pass serviceURL as additional param https://github.com/topcoder-platform/MS-Teams-bot-processor/blob/feature/teams-lambda/src/functions/request.js#L37, and here it could be persisted to DB via Central TC Lambda
https://github.com/topcoder-platform/Topbot/blob/central-lambda/src/functions/request.js#L74
Final Submission Guidelines
-
The git patches against the three repos
-
The updated Deployment Guide and Verification Guide (can be included in the patch file)
-
A simple text file to mention how to apply your patches.