8

I've enjoyed working with AWS Amplify a lot lately, its code generation for GraphQL queries based on defined schema is outstanding.

I came across one complication for defining custom logic / validation server-side. Out of the bag AppSync (part responsible for GraphQL api in Amplify) generates resolvers and DynamoDB tables for your schema. Resolvers are created using Apache Velocity templating language and if you are new to it, its a bit of a learning curve in my opinion.

Furthermore, these resolvers are auto generated by Amplify cli. I'm not sure if editing them makes sense either in AppSync console or locally, as every time we push api changes they will be auto generated again?

To add to this, these resolvers that are auto generated actually achieve a lot in terms of linking type models together, enabling search and authentication checks, I really don't want to touch them since development velocity enabled by automatic generation is insane.

Hence only other solution to introduce my custom logic seems to be Lambda functions that listen for create / update events of associated DynamoDB tables.

I think I can set this up in a way thats demonstrated below, essentially allowing users to use GraphQL api normally and when action that requires server validation is made react to it in lambda?

For example player adds item to their inventory, we fire lambda function to check if player had this item before, if not it was purchased, we validate item data and subtract gold of its cost from player table. I think this works fine but my concerns are

  1. We allow to write unvalidated data to database first (although it is validated by graphql type system and auth check prior.)
  2. Additional costs for involving Lambda (in my opinion worth it for time saving and ability to use NodeJS instead of Apache Velocity to define language)

Am I missing something else?

enter image description here

So lambda will do validation behind the scenes, we assume majority of users are good actors here and data they pass to GraphQL api is correct since they use our client.

In case data is unexpected (bad actor) lambda will react and ban the user.

Is this solution viable / common, is there other alternative?

Ilja
  • 44,142
  • 92
  • 275
  • 498
  • Lambda polls the ddb stream for anything new and invokes your lambda function synchronously. The check for a bad actor might not happen immediately so there may be consequences with that. Right now, AppSync resolver execute against a single data source. You can nest your queries to pass context between multiple resolvers as outlined in this [article](https://hackernoon.com/graphql-authorization-with-multiple-data-sources-using-aws-appsync-dfae2e350bf2) I will +1 your request as a feature req. Please keep tuned to the latest AppSync announcements in the future. – Lisa M Shon Oct 21 '18 at 15:32
  • 1
    You can edit those resolvers. Each resolver you overwrite in your `resolvers/` folder, will be used and no resolver will be autogenerated. – J. Hesters Jun 30 '19 at 13:35
  • I had the exact same question -- how are people using amplify doing server-side input validation? Amplify makes it super-easy to define a schema, but needing to write resolvers to do validation seems to defeat the whole purpose of using graphql. Doing post-create validation seems overly complex to me. There's an outstanding feature request (https://github.com/aws-amplify/amplify-category-api/issues/447) to enable simple validation, but I'm wondering what people are currently doing, but it's been open almost as long as this question... – Travis May 09 '23 at 01:56

0 Answers0