On the previous page we saw that invoking our function locally returns an error
http -b POST $(chalice url)/donor/signup first_name=ivica
will error with:
One of the principles of 12-factor apps states that configuration should be stored in the environment. Having configuration in the environment allows us to use the same codebase in different scenarios: one set of configuration for the sandbox (development) account and another one for our production account.
Setting and changing environment variables in Chalice is done through the .chalice/config.json
file.
Make the change by executing:
cat > .chalice/config.json <<EOF
{
"version": "2.0",
"app_name": "$WORKSHOP_NAME-savealife",
"stages": {
"dev": {
"api_gateway_stage": "api",
"environment_variables": {
"TABLE_NAME": "$WORKSHOP_NAME-savealife-dev"
}
}
}
}
EOF
After making the changes with the command from above, your .chalice/config.json
file looks similar to:
Deploy the changes.
If everything went well the Lambda function in AWS will have the environment variable configured and the code will read it.
Invoke the function again to make sure this change was applied:
http -b POST $(chalice url)/donor/signup first_name=ivica
will return null
because an exception was caught. Let’s see what is going on with
chalice logs
:
Even though we still can’t perform the PutItem
operation the name of the table is now shown correctly as ivica-savealife-dev
. A small victory, but a victory.
The following page will deal with the required permissions.