Is your feature request related to a problem? Please describe.
When creating a BatchPutItem template, I have to provide the table name for the batch operation.
Since I create my table via Cloudformation and with an ENV value attached, I cannot use the BatchPutItem since I don't have access to the current Environment value in the resolver template.
A workaround I am using right now is the first call a Lambda in a pipeline resolver and passing on the Environment value from the first function to the second that does the batchPutItem.
However, this is kinda unnecessary and requires an extra lambda call while the ENV value should be available during runtime. It looks like it is just not exposed via $ctx.
Describe the solution you'd like
Expose the environment value in the $ctx object.
@mattiLeBlanc Are you referring to a lambda environment variable or a parameter?
Currently in AppSync you can pass the table name as a field in the schema otherwise you'll need to specify the table name in the request mapping template. This seems similar to this following feature request #996 . I'll review this issue with the team as well.
My Function resolver (Appsync Pipeline) uses a BatchPutItem
:
#set($postsdata = [])
#foreach($id in ${ctx.args.groups})
#set($item = {
"pk": $id,
"sk": "POST:POST_ID=$ctx.stash.postId",
"type": "POST_IN_GROUP",
"title": $ctx.args.title
})
$util.qr($postsdata.add($util.dynamodb.toMapValues($item)))
#end
{
"version" : "2018-05-29",
"operation" : "BatchPutItem",
"tables" : {
"coralconsole_$ctx.stash.env": $utils.toJson($postsdata)
}
}
and as you can see I am using a stashed env variable at the table name in an attempt to make this work.
However, in Cloudformation we already have an ENV variable available so it might be possible to expose that into the $ctx object so that we don't have to a call a Lambda function in a pipeline to be able to specify the unique environment table name.
I also have same issue. On top of that how do I add table name when I am testing api locally?
👍 Also having issues with Batch*Item operations - table name differs per environment.
The resolver pipeline has an association with the DataSource. Why is table name inherent for Query, PutItem, GetItem, but needed for BatchItem operations?
I'd rather not shell out to a lambda to evaluate.
workaround of a pipeline where you use a lambda to import the environment variables into the stash will impact performance in bigger appsync apis.
with batchGetItem you really see that appsync is still in it's beginning stages.
really hope that aws will add environment variables for mapping resolvers.
adding the option for getting the type name and field name in the resolver would also be great.
and remove the BS option that you need to set the database name again, even with a datasource with that database added, that is just a straight up bug in aws appsync.
One way we resolved this is by using the AWS CDK to provision our Cloud Resources.
When we build our DIST, we read the templates of the resolvers and inject the database name.
Then that is deployed.
Works pretty well.
@mattiLeBlanc hmm that could be a good workaround. could you share some of that code that you made with AWS CDK to accomplish that?
I’ll see if I can make an extract of our setup.
To be continued
On Fri, 20 Dec 2019 at 19:10, robboerman2 notifications@github.com wrote:
@mattiLeBlanc https://github.com/mattiLeBlanc hmm that could be a good
workaround. could you share some of that code that you made with AWS CDK to
accomplish that?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aws-amplify/amplify-cli/issues/1774?email_source=notifications&email_token=ABIKJK5L63ANSXJRYWOIEELQZR4WJA5CNFSM4H5HYCX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHMHJFQ#issuecomment-567833750,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABIKJKZM4FY6T3DQZSXVPNDQZR4WJANCNFSM4H5HYCXQ
.
@mattiLeBlanc ok, waiting patiently on your response :)
Hi Rob,
Well it is a bit hard to give you our full CDK implementation because we haven't open sourced it (yet). Still in development.
But the bit where we doing the injection is where we define the template for a resolver:
/**
* Add a Resolver to the API
*/
public addResolver(config: ResolverConfig) {
const options: any = {
apiId: this.api.attrApiId,
typeName: config.type,
fieldName: config.name,
requestMappingTemplate: this.addEnv(ResolverService.Instance.resolvers[ config.type ][ `${config.template}-req` ]),
responseMappingTemplate: ResolverService.Instance.resolvers[ config.type ][ `${config.template}-res` ]
};
if (config.kind === ResolverKind.PIPELINE && config.pipelineFunctions && Array.isArray(config.pipelineFunctions)) {
options.kind = ResolverKind.PIPELINE;
options.pipelineConfig = {
functions: []
};
config.pipelineFunctions.forEach(name => {
options.pipelineConfig.functions.push(this.pipelineFunctions[ `${name}` ].attrFunctionId);
});
} else {
options.dataSourceName = config.dataSourceName;
}
return new CfnResolver(this, `Resolver_${config.name}`, options);
}
The important bit here is the this.addEnv
which is used at the requestMappingTemplate
property.
This function is nothing more then an concat function:
protected addEnv(template: string) {
return `#set($env=${JSON.stringify(this.resolverEnvironment)})\n${template}`;
}
The resolverEnvironment
is a property of an AppSync Construct (class) that creates a AWS Resource using the Constructs (check the CDK example for Typescript).
So when you deploy your API for an environment (local, dev or staging etc..) it will automatically inject the $env
variable in your template.
@mattiLeBlanc thanks for the example, this will help.
@mattiLeBlanc thanks for the example, this will help.
I hope it does. We found implementing the CDK pretty cumbersome at the start, especially with a bigger project with 3 stacks and one root stack. But I hope you will figure it out. Otherwise, just ask me in this thread.
@mattiLeBlanc I was unable to find resolverEnvironment anywhere in https://github.com/aws-samples/aws-cdk-examples, or any of the docs, are you referring to another git repo/cdk constructs example code?
Adding an update here that as of now AppSync does not support adding environment variables into resolver functions. We are looking at other ways we can address this. We also welcome any PRs or discussions on potential solutions on this.
+1 for this feature
Recently was using Amplify+AppSync and had to create custom resolvers for BatchPutItem
. Works well when deployed, but because of the table name being different when I develop locally with amplify mock api
the resolver becomes essentially useless.
@mattiLeBlanc I was unable to find resolverEnvironment anywhere in https://github.com/aws-samples/aws-cdk-examples, or any of the docs, are you referring to another git repo/cdk constructs example code?
Sorry for the late reply:
resolverEnvironment
is something we added to our own Stack, so it is not a standard property you would find like region
or account
.
We get our environment from process.env.ENV
and we set it in Bitbucket (deploy variables) or in our local terminal env variables.
Does that make sense?
+1 for that feature.
Any news on that?
Thx and all the best!
yes already supported, trough substitutions
yes already supported, trough substitutions
May you please provide some more details - also an example would be great. Really appreciate your support!
I'm also vouching for that. Having to manage these table names in resolver is a real pain in the butt. People don't think about it and push the resolvers code to git with the table names changed all the time.
There should be an easy way to get the table names in the given environment, that would be a life saver.
And don't tell me, well just ask people not to push these modified files, you know people, they forgot as soon as you let them go. That's human nature's...
+1 :+1:
Pretty much a deal-breaker feature that's missing at the moment.
Most helpful comment
+1 :+1:
Pretty much a deal-breaker feature that's missing at the moment.