## For VTLs #TODO need to list out pros of using VTLs here. Yan Cui has [Twitter thread](https://twitter.com/theburningmonk/status/1332211508198117376) on this, generally arguing in favour of VTLs as the default choice. ## Against VTLs My issues with [[AppSync VTL resolver]]: - VTL testing feedback loop is too slow. With JS, I just invoke my handler locally and can test my DDB query is returning expected results. - Logic for creating computed PK and GSI fields is C&P across multiple VTLs but can be centralised easily in JS module. This happens a lot with single-table designs. - Setup for integration tests involves writing JS data access code to seed the DB. I can re-use the data access code from my Lambda handlers but if I'm just writing VTLs, I need to recreate the VTL DDB requests in JS, just for creating test data. - When something gets sufficiently complicated to warrant ejecting from VTL (e.g. I need to update a denormalised copy of data inside a txn), I need to rewrite everything in JS, not just add the extra stuff. Then rewire all the resolver config ## References - [RFC: JavaScript Resolvers in AWS AppSync](https://github.com/aws/aws-appsync-community/issues/147)