DEV Community

Direct Lambda Resolvers with AWS Amplify and AppSync

Matt Marks 🐣 on August 12, 2020

How I feel about VTL on any given day Haha okay, okay. I'm just kiddin' (mostly). AWS recently announced Direct Lambda Resolvers su...

Read full post

swyx • Aug 17 '20

Syntax Error: Expected Name, found @

GraphQL request:4:9
3 |   id: ID
4 |   task: @function(name: "DirectLambdaResolver-${env}")
  |         ^
5 | }

Matt Marks 🐣 • Aug 17 '20

Thank you Shawn for catching this, it's a treat just to have you actually use this code!

swyx • Aug 17 '20

not at all lol, i barely know what i'm doing and was following along just to try to learn about this new feature 😅

i think the struggle i had was how to use direct lambda resolvers in mutations not just queries. i couldnt figure out how to do it. maybe worth a followup post?

Matt Marks 🐣 • Aug 17 '20

Pfffh, you got it. I'll whip something up for this week.

Nxtra • Nov 20 '20

Did you guys manage to figure this out?

Matt Marks 🐣 • Nov 20 '20 • Edited

@nxtra , in order to do this for a mutation, you'd set the typeName: Mutation and fieldName: yourMutationName. Query, Mutation and Subscription are really just a Type like Todo.

The one gotcha is that you can't create a resolver on a mutation that already has one. Example being createToDo. Amplify has already created a resolver for it inside CloudFormation. You'll need to either to add @model(mutations: null) so you can override it or create a custom mutation. I prefer the custom mutation because then I still have access to the autogenerated vtl from Amplify. There are times where the authorization rules that are generated in the response.vtl can still be useful.

  "MutationyourMutationNameLambdaResolver": {
  "Type": "AWS::AppSync::Resolver",
  "Properties": {
    "ApiId": {
        "Ref": "AppSyncApiId"
    },
    "DataSourceName": "DirectLambdaResolverLambdaDataSource",
    "TypeName": "Mutation",
    "FieldName": "yourMutationName"
  },

  "DependsOn": "DirectLambdaResolverLambdaDataSource"
}

Nxtra • Nov 23 '20

Thanks for the info! I didn't realize yet that indeed a resolver with that name already exists if you name it like that.
Until now I've been making custom Resolvers with lambda functions as pipeline resolvers. I'll try to convert one to a "no-more-vtl" version using your guide.

Michael Brant • Dec 11 '20

I'm confused, I thought the whole point of the Amplify cli was so I wasn't modifying cft's directly?

Matt Marks 🐣 • Dec 14 '20

I'd also say the intent of Amplify is to offer you a core set of services that includes authentication, database, file storage, analytics, managed hosting, deployments, with more and counting.

The services are supposed to make it more accessible and approachable for backend and front-end devs, which on the whole, they absolutely do. They're still growing and figuring things out though and in the meantime, they've given the option of customizing your CFTs when you need to do something off the beaten bath.

Matt Marks 🐣 • Dec 14 '20

It's almost inevitable that you will modify CFTs in the future. Amplify offers a lot out of the box but there are several solutions that they don't offer from the cli.

Rich Adams • Dec 31 '20

I followed the above, but now the lambda is no longer invoked and the field that previously had the @function now comes back with a null value; any suggestions as to what may be wrong? Thanks!!

Matt Marks 🐣 • Feb 8 '21

Hey Rich, I’d have to know more about your project and see your CustomResources.json file

Nxtra • Oct 1 '20

Is there any risk in breaking this when you regenerate code or add other resources with Amplify? Or once you've done this it's stable?

Matt Marks 🐣 • Oct 2 '20 • Edited

As long as you keep the code in the CustomResources file (or another custom stack) and you make sure to remove the @directive, you’re good.

These days I mostly use amplify for its api/auth/appsync integration and the cli for generating as much code as possible because I’m lazy ;)

Nxtra • Oct 7 '20

Awesome, thanks!