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

Question

1. 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?

2. Also, is there any Playground to check & play with VTL just like we can do with JavaScript in Web Console?

3. Can we work with AWS AppSync offline & check if everything written in VTL works as expected?

Frans

1. Thanks for bringing this up. I am on the AWS AppSync team and will follow up internally with a feature request on your behalf. 2. You can currently test your mapping templates using a mock/test data via AppSync Console. 3. Approach #2 does not involve a round trip to the DataSources and the test data is used to validate your templates. – Possum

Thanks @ShankarRaju Also, the docs aren't quite there yet. So please just make them better if you can. Here's my relevant problem twitter.com/deadcoder0904/status/997431929346707456 – Frans

Will take your feedback to the team. Thanks for your input. – Possum

@ShankarRaju It is a junk way of introducing one more language for these templating. Why not use a widely used programming language such as nodejs, python as we are purely dealing with data objects. I never saw anyone in my 25+ years of experience who knows VTL and I don't see a need for it. – Yearly

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) )

Araujo

i'll tick the answer when i work with appsync again till then have an upvote :) – Frans

It is called a half-baked product that is released to production by AWS – Yearly

it is nightmare to debug AppSync VTL :-( – Boughpot

Why didn't I find the above two comments before I started with AppSync?... – Unwept

Is it still the only/best way to log/debug VTL in AppSync? – Holloway

AWS released a update for Amplify. where they got some local vtl debugging support. aws.amazon.com/blogs/mobile/amplify-framework-local-mocking but still a nightmare to debug VTL in general – Collyrium

Awesome, thanks! VTL is nasty, but at least your solution gives us a chance to debug it. – Washtub

There is a proper way now to debug it in 2020? has something been changed, I saw the article above where you can check for syntax error but not for proper debugging. Hope there is any news on that. – Supramolecular

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"
    }
  ]
}

Unhouse

I found this very useful, so upvote from me. I used it like this to better align it with the error object just for readibility: $util.error("DEBUG", 'REQUEST', null, $postBody) Which gives a response like this: "message": "DEBUG", "errorType": "REQUEST", "data": null, "errorInfo": "{\"postBodyStuff\":\"whatever\"}" – Grig

Printing the context and these info fields is helpful: $util.error($util.toJson($context), $util.toJson($context.info.selectionSetList), null, $util.toJson($context.info.selectionSetGraphQL)) – Seale

Answer 3

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

Guard

This should be the accepted answer now. Glad they added an actual logging utility - thanks! – Confetti

Answer 4

The answers to each of your 3 questions are as follows:

1. 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).
2. A Playground for VTL experimentation exists in the AWS AppSync console where you you can edit and test the VTL for your resolvers.
3. 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.

Simons

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.

Cryan

Answer 6

This question is old, and a lot has happened since the question was asked. I'll try to bring more up-to-date insights.

First of all, it's worth mentioning that AppSync now supports JavaScrit resolvers. This is a game changer when it comes to Developer Experience. I highly recommend t.

To answer the original questions:

1. Both VTL and JS resolvers now both support logging.

With JS resolvers, you can simply use console.log(). The logged data will show up in CloudWatch.

2. Testing resolvers is now possible.

The aws CLI comes with a command that allows you to test resolvers without having to deploy and invoke a Query. See the doc

3. As other mentioned, some solutions are available to test AppSync locally (namely, Amplify CLI). However, I would not recommend it. Instead, I prefer testing directly in the cloud. t gives more confidence that it works as expected. Unfortunately, it is still a bit of a pain (because of deployment time), but hopefully, this will improve over time thanks to features like CDK hotswap, SAM accelerate, etc.

You can also use the evaluation command to write unit/integration tests

Additionally to all the above, which are "built-in" solutions, I created an app, GraphBolt, that aims to improve AWS AppSync DX and tres solve some of the pain points mentioned here.

Regimen

Answer 7

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.

Reverberation