Bamboo Lambda

Our serverless stack.

Setup

• yarn install - install the dependencies
• cp src/config/example.local.config.json src/config/local.config.json to setup the config then fill in the bits. You may need API keys from one of the other devs. The rest of the config values will be set automatically after you first run yarn deploy

Scripts

• yarn dev starts what you need to begin developing
• yarn test:unit executes the unit tests
• yarn test:integration executes the integration tests (against the actual server)
• yarn test:integration:only TEST executes just that one test (or group of tests if you use describe())
• yarn test:integration:quick executes all integration tests except for some that take a long time (Basiq)
• yarn test executes all tests once
• yarn test:unit:watch exectutes unit tests in watch mode
• yarn log FUNCTION starts logging the function name
• yarn invoke FUNCTION calls the function and returns the logs
• yarn deploy:only FUNCTION deploys just that function, useful for rapid iterative development
• yarn deploy deploys the entire serverless stack and runs some post-deploy scripts
• yarn pretty runs prettier on the whole project, make sure you commit before running this so not to confuse your commit
• yarn set:stage STAGE will update your local config with the parameters pulled from cloud formation (you need the AWS CLI installed for this)

Testing

• There are unit test which run before the build and are run in watch mode as part of yarn dev. These should test internal business logic
• Integration tests after deploy and make actual calls to the server to test end-to-end functionality
• If you need to see what fetch calls are being made in your src/config/local.config.json add "LOG_FETCH": true, and now fetch calls should be logged to the console.

Deploying - READ!!

• There is a known issue currently with deploying new stack. If you are deploying for the first time you will get errors unless you comment out the line that reads AWS_USER_POOL_ID: ${cf:${self:custom.stackName}.UserPoolId} from serverless.yml. This is because we are trying to get the UserPoolID from the current stack, but it needs the stack to be deployed already before it can do that. On the second deploy you can put the line back in again and it should be fine. This is a known issue and we are trying to work through it on this issue: https://github.com/serverless/serverless/issues/4940

Coding Standards

• This project runs a pre-commit git hook that executes "prettier" on changed files to ensure a common coding standard

Request Response Flow

1. CLIENT => 2) GATEWAY => 3) HANDLER => 4) DOMAIN => 5) HANDLER => 6) GATEWAY => 7) CLIENT

2. Client initiates a request to the gateway

3. Gateway authorizes the request and passes to the lambda handler

4. Handler validates input and translates into a strong type before passing to the domain

5. Domain performs the actual logic for the call, can be assured that the input has been validated

6. Handler translates the domain response into the expected response from client

7. Response passes back through gateway before..

8. Client recieves response

Visual Studio Code

If you are using Visual Studio code for editing we have some reccomended extensions and settings:

Extensions

• Blueprint - for templating (see blueprint-templates dir)
• vscode-icons - for better icons in vscode
• Prettier - for better icons in vscode

Other

• To build the cognito-user-pool.yml I ran aws cognito-idp describe-user-pool --region ap-southeast-2 --user-pool-id ap-southeast-2_aaWkuRqqc then copied over the result
• We are using --forceExit on the integration tests because of this issue in jest: https://github.com/facebook/jest/issues/6639