I'm following the steps here https://aws-amplify.github.io/docs/cli/graphql#add-a-custom-resolver-that-targets-an-aws-lambda-function but in the steps that says: _Add the function as an AppSync data source in the stack鈥檚 Resources block._. Ok, but, and the template? which one? _amplify\backend\api\myapi\stacks\CustomResources.json_ or should I add a new one in _amplify\backend\api\myapi\stacks_? Obviously, it is not in the Lambda's template because of the parameters S3DeploymentBucket
and S3DeploymentRootKey
are not injected/passed to the Lambda's template, right?
I think the documentation is not clear about the process and should be updated accordingly.
@kstro21 Thanks for the comment. You are able to add the resource to any stack in the stacks directory of the API project's stacks directory. You may add it at amplify\backend\api\myapi\stacks\CustomResources.json
or amplify\backend\api\myapi\stacks\SomeOtherTemplate.json
and both will be fed the parameters & uploaded to S3 on push. I will make a note to update the docs with more clear information in this regard.
https://aws-amplify.github.io/docs/cli/graphql#api-category-project-structure basically describes this structure, but it would be very useful if the documentation at https://aws-amplify.github.io/docs/cli/graphql#add-a-custom-resolver-that-targets-an-aws-lambda-function referenced the first link.
Thanks, @mikeparisstuff I've tested both approaches and works.
Additionally, https://aws-amplify.github.io/docs/cli/graphql#add-a-custom-resolver-that-targets-an-aws-lambda-function is somewhat misleading / incomplete.
Firstly, the DataSource
needs a DependsOn: DataSourceRole
, and the Resolver
needs a DependsOn: DataSource
, otherwise the cloudformation template will fail to create.
Additionally, as noted in https://github.com/aws-amplify/amplify-cli/issues/986, since the cloudformation stacks are named so arbitrarily, getting the GraphQLApiId
export from the parent stack is extremely difficult. You can get around this with the following:
"ApiId": {
"Fn::ImportValue": {
"Fn::Join": [
":",
[
{
"Fn::Select": [
0,
{
"Fn::Split": [
"-CustomResourcesjson-",
{
"Fn::Sub": "${AWS::StackName}"
}
]
}
]
},
"GraphQLApiId"
]
]
}
but it's very much not ideal.
@zjullion You should be able to reference the ApiId directly from the stacks paramters. Here is an example:
The parameter definition that you can add to your template:
Example usage of the parameter:
@mikeparisstuff but that only will work for templates inside amplify\backend\api\myapi\stacks\
, If we want to get that value from a template of a Lambda function, we can't.
@mikeparisstuff thank you for that, it's much cleaner and simpler than what I was doing. Obviously, the AppSyncApiId
parameter is being passed in to any stacks we create under myapi\stacks
by Amplify. Is there a documented list anywhere of which parameters are passed in by amplify to custom stacks? Knowing that would be pretty useful.
@zjullion yes, it's much cleaner and simpler for any stacks we create under myapi\stacks
, but, if I'm writing a Lambda and I need the AppSyncApiId
, how do I get it? It is not crystal clear. The export name is so random that we will need to amplify push
, wait to finish, copy the export name, hardcode it in the CloudFormation template, then run amplify push
again.
But then, if you want to create a new env, it becomes really hard to maintain. See the point? It would be really nice to have #986 but I started to note another issue, the order in which the stacks are created/updated is a mess. #986 will also require that some DependsOn
be added to make sure we are not trying to get an export from stacks that are not created yet. It sounds like it could be another feature request :-)
CC: @mikeparisstuff
@kstro21 Thanks for the comment. You are able to add the resource to any stack in the stacks directory of the API project's stacks directory. You may add it at
amplify\backend\api\myapi\stacks\CustomResources.json
oramplify\backend\api\myapi\stacks\SomeOtherTemplate.json
and both will be fed the parameters & uploaded to S3 on push. I will make a note to update the docs with more clear information in this regard.
@mikeparisstuff Just out of curiosity these CFN templates have to be json or can they be written in YAML?
I'm also confused how to get AppSyncApiId
in a function stack. It seems env
parameter is being passed in by nested-cloudformation-stack.yml
at path amplify/backend/awscloudformation/
. Is it possible to pass AppSyncApiId
parameter so we can easily use it in our lambda resolvers?
I'm trying to set it as lambda environment variable so I can use it to call the correct dynamodb table which uses this value to suffix the table name.
Is there another way to get this value currently? Please let me know, I'm stuck.
@cocacrave Yes, if you define the parameter in your stack it will be passed down. See https://github.com/mikeparisstuff/amplify-cli-nested-api-sample/blob/7c4c7dec85b4f27e8344bea6063b4d85cf48771f/amplify/backend/api/amplifynestedsample/stacks/CustomResources.json#L5 for an example. The Amplify API category will automatically wire up your custom stacks to get this param when specified.
I agree that the docs for adding a custom resolver should include a link to https://aws-amplify.github.io/docs/cli-toolchain/graphql#api-category-project-structure . In fact, I really wish I had read about the API Category Project Structure a long time ago. Until I read that section, I had no understanding of what amplify push
was actually doing or how it worked. I think it would be a good idea to make that article much more prominent than it is now. You have to go really deep in the docs past a lot of advanced topics to find it right now, but it really should be one of the first things you read when learning about Amplify.
Most helpful comment
I agree that the docs for adding a custom resolver should include a link to https://aws-amplify.github.io/docs/cli-toolchain/graphql#api-category-project-structure . In fact, I really wish I had read about the API Category Project Structure a long time ago. Until I read that section, I had no understanding of what
amplify push
was actually doing or how it worked. I think it would be a good idea to make that article much more prominent than it is now. You have to go really deep in the docs past a lot of advanced topics to find it right now, but it really should be one of the first things you read when learning about Amplify.