To start, we’ll create several functions that, when taken collectively, could be considered to be our Account Applications service. Namely, we’ll make functions allowing us to submit new applications (consisting of just a record with a name and an address), flag applications for review, and mark applications as approved or rejected. We’ll also add a capability to list all applications in a certain state (like SUBMITTED or FLAGGED) to save ourselves the trouble of inspecting the service’s data store directly.
Install the AWS SAM CLI
➡️ Step 1. In your Cloud9 workspace’s terminal command line, run this command to install Homebrew, a package manager that we’ll use to install the AWS SAM CLI. Note: you’ll need to press enter when prompted to continue the install.
# Install Homebrew /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
➡️ Step 2. Now, run these commands to install the SAM CLI and all of the housekeeping of getting the first versions of our services deployed:
# Then get brew into our $PATH test -d ~/.linuxbrew && eval $(~/.linuxbrew/bin/brew shellenv) test -d /home/linuxbrew/.linuxbrew && eval $(/home/linuxbrew/.linuxbrew/bin/brew shellenv) test -r ~/.bash_profile && echo "eval \$($(brew --prefix)/bin/brew shellenv)" >>~/.bash_profile echo "eval \$($(brew --prefix)/bin/brew shellenv)" >>~/.profile # Install the AWS SAM CLI brew tap aws/tap brew install aws-sam-cli # Bootstrap our initial services into ./workshop-dir git clone https://github.com/gabehollombe-aws/step-functions-workshop.git cp -R step-functions-workshop/sam_template/ workshop-dir # Change to our new directory cd workshop-dir
➡️ Step 2. Use the SAM CLI to build our Lambda functions in preparation for a deploy.
From the terminal, run:
➡️ Step 3. Use the SAM CLI to deploy our Lambda functions and DynamoDB table
From the terminal, run the following command and respond to the interactive prompts in a similar fashion. Then wait a few minutes for the deploy to finish.
# Run our first deploy in guided mode. Answer the interactive questions the same way that the comments show below: sam deploy --guided # Please respond to the interactive questions like this: # Stack Name [sam-app]: step-functions-workshop # AWS Region [us-east-1]: ENTER_THE_SAME_REGION_AS_WHERE_YOUR_CLOUD9_INSTANCE_IS_RUNNING_FROM # Confirm changes before deploy [y/N]: N # Allow SAM CLI IAM role creation [Y/n]: Y # Save arguments to samconfig.toml [Y/n]: Y
While you’re waitin for the deploy to finish, take a few moments to look at some of the files we just created in
workshop-dir to understand what we deployed.
Here are some important files worth looking at:
This implements our SubmitApplication Lambda function. There are similar files for
approve as well.
This is a common file that provides CRUD style operations for our Account Application data type. It’s used by the various
functions/account-applications/*.js Lambda functions.
This implements our DataChecking Lambda function. It contains code to handle requests to check a name and an address against some simple validation rules.
This is the file that AWS SAM looks at to determine what we want resources we want to cloud create and deploy as part of our solution. If you’re familiar with AWS CloudFormation, the structure of this file will look pretty familiar to you, because AWS SAM is just a set of conveniences built on top of CloudFormation.
Now we have fully-deployed Lambda functions that can handle all of the steps involved to move an application from SUBMITTED, to FLAGGED, to APPROVED or REJECTED. And, we also have a stand-alone data checking Lambda function which we’ll use later in our orchestration.