diff --git a/.DS_Store b/.DS_Store deleted file mode 100644 index 587aaad..0000000 Binary files a/.DS_Store and /dev/null differ diff --git a/Lambdas/.DS_Store b/Lambdas/.DS_Store deleted file mode 100644 index d4384bd..0000000 Binary files a/Lambdas/.DS_Store and /dev/null differ diff --git a/Lambdas/Lists/Chain/src/README.md b/Lambdas/Lists/Chain/src/README.md new file mode 100644 index 0000000..84024a6 --- /dev/null +++ b/Lambdas/Lists/Chain/src/README.md @@ -0,0 +1,16 @@ +# Chain Module +Deals with information concerning store chains supported by the product populating and product serving Lambdas. + +### ChainGET +#### Expected request body: +N/A + +#### Expected query parameters: + - id + - Used for specifying which chain to retrieve + - Valid values: -1,1 API Gateway endpoint -> Lambda -> (same) API Gateway endpoint -> (same) Client + | . | . + \ / / \ \ / / \ + ' | ' | + AWS Cognito MariaDB instance/Other AWS services(SES, Cognito) +``` + +### Scraping +Contains logic to orchestrate runs using a scraping utility to collect merchant data and store it in the database + + + + +## Common Troubleshooting +#### Logs +- Logs may be written to by printing to the stdout. (Fancier logging is also possible, but currently not implemented) +- Logs are avalaible on AWS's Cloudwatch under Log Groups -> {Lambda name} +- Logs typically persist after deletion of the associated Lambda + +#### Incomplete runs +Often if a run fails to complete, it is because the standard allocated time and memory/cpu is inadaquate. +- Symptoms: + - The running time (available in the Cloudwatch logs) is almost exactly the maximum time. +- Resolutions: + - Time may be increased. + - CPU may be increased. CPU is proportional to memory, so CPU is increased by increasing memory allocation. diff --git a/Tooling/README.md b/Tooling/README.md new file mode 100644 index 0000000..7192c49 --- /dev/null +++ b/Tooling/README.md @@ -0,0 +1,68 @@ +# Tooling + +This folder contains supporting scripts to automate the serverless backend resource creation/updating. + + +## Scope +The scripts here will create and update AWS Lambdas and their paired API Gateways as well as attaching appropriate IAM roles to the Lambdas and Cognito integration to the API Gateway. + +Covered: + - AWS Lambdas + - AWS API Gateway + - AWS IAM <-> AWS Lambda interaction + - AWS Cognito <-> API Gateway interaction + +Not covered: + - Verification of Lambda correctness: These scripts will in no way verify that the built jar is correct. + + + +## Files + +#### EndpointSetup.sh + - Purpose: Creates a new AWS Lambda, and, if needed, a new API Gateway endpoint and HTTP method on the endpoint. The names are autogenerated based on the method and the input name. + - Inputs: + - Resource name: Name of the resource (e.x. List). + - HTTP method: HTTP method to use to access this particular Lambda. Will be appended to resource name to get expected Java class (e.x. resourceGET) + - Resource jar: The script will search the project directory for a jar with the given resource name (resource.jar). The jar should contain all method classes for the resource as well as any dependencies. + +#### LambdaUpdate.sh + - Purpose: Refreshes the jar attached to a specific Lambda. + - Inputs: + - Resource name: Name of the resource (e.x. List). + - HTTP method: HTTP method to use to access this particular Lambda. Will be appended to resource name to get expected Java class (e.x. resourceGET) + +#### VarSetup.sh + - Purpose: Sets up some constants related to the AWS account and basic resources (e.x. broad API gateway id, Cognito pool). Collects constants for easy modification + + + + +## Running + +``` +$ bash Tooling/EndpointSetup.sh +Creating a Gateway/Lambda pair. +Please enter base function name: List +Please enter method(GET, POST, etc.): PUT + +``` + +``` +$ bash Tooling/LambdaUpdate.sh +Updating a Lambda. +Please enter base function name: List +Please enter method(GET, POST, etc.): PUT +Update successful. +``` + +VarSetup.sh should not need to be called directly since the other scripts `source` it. + +## Debugging + + VarSetup.sh has a `DEBUGFILE` constant in it. By default it is `/dev/null`, but you can change it to something else to get debugging output. + +## Notes +- Many configurations are stored as constants in the scripts and can be modified. Most of these constants should be in VarSetup.sh, but some may be elsewhere. +- Sometimes the allocated memory and/or runtime is insufficient and must be adjusted upwards. +- If in Windows Subsystem for Linux, you may have to remove '\r' characters that Windows added to the .sh files.