* Which Category is your question related to? *
Amplify has environment variables but they seem to only be used in client builds. How can these environment variables be used on the backend?
* What AWS Services are you utilizing? *
Amplify CLI multienv function
* Provide additional details e.g. code snippets *
What's the intended what to feed secrets to the multienv backend? There seems like a disconnect between the Amplify Environment variables defined in the console and the backend.
Sorry to pose the question here. I'm hungry for more documentation.
Thanks
@brian-young- Do you want to pass the env variable to your lambda function created using the CLI?
If you look at your Cloudformation template generated by the Amplify CLI for functions (lambda), youll observe this block:
"LambdaFunction": {
"Type": "AWS::Lambda::Function",
"Properties": {
"Handler": "index.handler",
"FunctionName": {
"Fn::If": [
"ShouldNotCreateEnvResources",
"test968e4b439",
{
"Fn::Join": [
"",
[
"test968e4b439",
"-",
{
"Ref": "env"
}
]
]
}
]
},
"Role": {
"Fn::GetAtt": [
"LambdaExecutionRole",
"Arn"
]
},
"Runtime": "nodejs8.10",
"Timeout": "25",
"Code": {
"S3Bucket": "test9-20190108121715-deployment",
"S3Key": "amplify-builds/test968e4b439-1546978705-latest-build.zip"
},
"Environment": {
"Variables": {
"ENV": {
"Ref": "env"
}
}
}
}
}
The environment varibale is actually passed o your lambda function which you can reference it in you r lambda function as process.env.ENV
.
@brian-young- here be dragons (see also: #621). The backend stuff feels incredibly immature and I'm finding myself sinking a TON of time into workarounds. (Example: good luck calling the GraphQL api Amplify generates for you from a backend Function also generated by Amplify – aka querying your database from your "server".)
Edit: Sorry for the mini-rant above. In the spirit of being more productive, what I've taken to doing is creating a secret using AWS Secret Manager, manually storying environment config values (like contents of aws_exports.js
) there, indexed by environment key, modifying the CloudFormation template for each function to permit retrieval of that secret, and then using that to bootstrap further operations...
Troy, thanks. That approach will work.
Would be great if the environment vars specified in the console where pulled down and then included in the build of backend components.
@brian-young-, @troygoode opened up an issue (feature request) #689 to address this issue. Closing this issue since its a duplicate of https://github.com/aws-amplify/amplify-cli/issues/689
@brian-young- here be dragons (see also: #621). The backend stuff feels incredibly immature and I'm finding myself sinking a TON of time into workarounds. (Example: good luck calling the GraphQL api Amplify generates for you from a backend Function also generated by Amplify – aka querying your database from your "server".)
Edit: Sorry for the mini-rant above. In the spirit of being more productive, what I've taken to doing is creating a secret using AWS Secret Manager, manually storying environment config values (like contents of
aws_exports.js
) there, indexed by environment key, modifying the CloudFormation template for each function to permit retrieval of that secret, and then using that to bootstrap further operations...
@troygoode Would you be able to go into more detail about how to accomplish this?
Most helpful comment
@brian-young- here be dragons (see also: #621). The backend stuff feels incredibly immature and I'm finding myself sinking a TON of time into workarounds. (Example: good luck calling the GraphQL api Amplify generates for you from a backend Function also generated by Amplify – aka querying your database from your "server".)
Edit: Sorry for the mini-rant above. In the spirit of being more productive, what I've taken to doing is creating a secret using AWS Secret Manager, manually storying environment config values (like contents of
aws_exports.js
) there, indexed by environment key, modifying the CloudFormation template for each function to permit retrieval of that secret, and then using that to bootstrap further operations...