Where can I log & debug Velocity Template Language (VTL) in AWS AppSync? - amazon-web-services

Question

Is there any easy way to log or debug VTL coming from Request Mapping Template & Response Mapping Template rather than sending Queries & Mutations to debug & log?
Also, is there any Playground to check & play with VTL just like we can do with JavaScript in Web Console?
Can we work with AWS AppSync offline & check if everything written in VTL works as expected?

Answer 1

A super nasty way to log and debug is using validate in the response mapping
$util.validate(false, $util.time.nowISO8601().substring(0, 10) )

Answer 2

Here's how I logged a value in my VTL resolver:
Add a "$util.error" statement in your request or response template and then make the graphql call.
For example, I wanted to see what was the arguments passed as an input into my resolver, so I added the $util.error statement at the beginning of my template. So, my template was now:
$util.error("Test Error", $util.toJson($ctx))
{
"version" : "2017-02-28",
"operation" : "PutItem",
"key": {
"id": $util.dynamodb.toDynamoDBJson($ctx.arguments.user.id)
},
"attributeValues": {
"name": $util.dynamodb.toDynamoDBJson($ctx.arguments.user.name)
}
}
Then from the "Queries" section of the AWS AppSync console, I ran the following mutation:
mutation MyMutation {
addUser(user: {id: "002", name:"Rick Sanchez"}) {
id
name
}
}
This displayed the log results from my resolver as follows:
{
"data": null,
"errors": [
{
"path": [
"addUser"
],
"data": null,
"errorType": "{\"arguments\":{\"user\":{\"id\":\"002\",\"name\":\"Rick Sanchez\"}},\"identity\":null,\"source\":null,\"result\":null,\"request\":{\"headers\":{\"x-forwarded-for\":\"112.133.236.59, 130.176.75.151\",\"sec-ch-ua-mobile\":\"?0\",\"cloudfront-viewer-country\":\"IN\",\"cloudfront-is-tablet-viewer\":\"false\",\"via\":\"2.0 a691085135305af276cea0859fd6b129.cloudfront.net (CloudFront)\",\"cloudfront-forwarded-proto\":\"https\",\"origin\":\"https://console.aws.amazon.com\",\"content-length\":\"223\",\"accept-language\":\"en-GB,en;q=0.9,en-US;q=0.8\",\"host\":\"raxua52myfaotgiqzkto2rzqdy.appsync-api.us-east-1.amazonaws.com\",\"x-forwarded-proto\":\"https\",\"user-agent\":\"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36 Edg/87.0.664.66\",\"accept\":\"*/*\",\"cloudfront-is-mobile-viewer\":\"false\",\"cloudfront-is-smarttv-viewer\":\"false\",\"accept-encoding\":\"gzip, deflate, br\",\"referer\":\"https://console.aws.amazon.com/\",\"x-api-key\":\"api-key-has-been-edited-out\",\"content-type\":\"application/json\",\"sec-fetch-mode\":\"cors\",\"x-amz-cf-id\":\"AvTMLvtxRq9M8J8XntvkDj322SZa06Fjtyhpf_fSXd-GmHs2UeomDg==\",\"x-amzn-trace-id\":\"Root=1-5fee036a-13f9ff472ba6a1211d499b8b\",\"sec-fetch-dest\":\"empty\",\"x-amz-user-agent\":\"AWS-Console-AppSync/\",\"cloudfront-is-desktop-viewer\":\"true\",\"sec-fetch-site\":\"cross-site\",\"sec-ch-ua\":\"\\\"Chromium\\\";v=\\\"87\\\", \\\" Not;A Brand\\\";v=\\\"99\\\", \\\"Microsoft Edge\\\";v=\\\"87\\\"\",\"x-forwarded-port\":\"443\"}},\"info\":{\"fieldName\":\"addUser\",\"parentTypeName\":\"Mutation\",\"variables\":{}},\"error\":null,\"prev\":null,\"stash\":{},\"outErrors\":[]}",
"errorInfo": null,
"locations": [
{
"line": 9,
"column": 3,
"sourceName": null
}
],
"message": "Test Error"
}
]
}

Answer 3

The answers to each of your 3 questions are as follows:
To unit test request/response mapping templates, you could use the method described in this blog post (https://mechanicalrock.github.io/2020/04/27/ensuring-resolvers-aren't-rejected.html).
A Playground for VTL experimentation exists in the AWS AppSync console where you you can edit and test the VTL for your resolvers.
The Amplify framework has a mock functionality which mocks AppSync, the AppSync VTL environment and DynamoDB (using DynamoDB Local). This would allow you to perform e2e tests locally.

Answer 4

Looks like you are looking for this new VTL logging utility such as
$util.log.info(Object) : Void
Documentation:
https://docs.aws.amazon.com/appsync/latest/devguide/utility-helpers-in-util.html

Answer 5

When I realized how much a pain it was to debug VTL, I created a lambda (nodejs) that logged the contents of my VTL template.
// my nodejs based debug lambda -- very basic
exports.handler = (event, context, callback) => {
const origin = context.request || 'oops';
if (context && context.prev) {
console.log('--------with context----------------');
console.log({ prev: context.prev.result, context, origin });
console.log({ stash: context.stash });
console.log('--------END: with context----------------');
callback(null, context.prev.result);
}
console.log('inside - LOGGING_DEBUGGER');
console.log({ event, context: context || null, origin });
callback(null, event);
};
This lambda helped me debug many issues inside my pipeline resolvers. However, I forgot if I used it as a direct lambda or with request+response templates.
To use it, I put values that I wanted to debug into $ctx.stash in my other pipeline functions. Then in my pipeline, I added the "debugger" function after this step -- in case there was an issue where my pipeline would blow up before a fatal error occurred.

Answer 6

Check the $util.log.info(Object) : Void from CloudWatch logging utils
PS: you need to turn on logging to Amazon CloudWatch Logs plus setting Field resolver log level on ALL more details here.