Comment by Janusz on "Improving Developer Experience with TypeScript: How to Write Strongly Typed AppSync Resolvers"

Interesting article, although the statement that "AppSync uses the latest ES module version" is simply untrue and can lead to issues when working on something more than hello world. AWS docs clearly say that APPSYNC_JS supports only a subset of ES 6 functionality, and ES 6 = ES2015, after 2015 we had 17, 18, 19, 20, 21, 22, 23 & 24, so it's doesn't even come close to ESNEXT, which basically means "take latest".

Unless we get real implementation of APPSYNC_JS target for ESBuild we can only try to make things work. My suggestion would be to:

Switch target to ES6
Add one more step after the code gets transpiled that runs eslint configured with restricted AppSync syntax to make sure everything is up to the standard after transpilation

Unfortunately it's not a seamless experience as you can still stumble upon functionality that will transpile to something that can't work, but you would at least get clear error during build step when it happens.

Thanks for all the details Janusz.

That statement looks misleading, indeed, and I could clarify this point.

However, the AppSycn documentation recommends esnext as the target. (Well, they don't expressly recommend it but this is what they show in the examples).

docs.aws.amazon.com/appsync/latest/devguide/resol…

When I first experimented with TS resolvers (even before the aforementioned doc was written), I experienced issues with most non-esnext targets, even those that were supposed to be compatible. esnext was the only one that worked every time.

I am not a pro at transpiling and EsBuild, but my experience showed that using "esnext" as the target ensures that the transpiler will usually not try to "transform" any of your code. When using TypeScript, it merely removes any typing and keeps everything else as-is. It also bundles everything in a single file. Which is exactly what I want.

It is the responsibility of the developer to ensure that the code will be APPSYNC_JS compatible after that.

To avoid bad/incompatible code, I use the eslint plugin at development time. And if for any reason my code would still be incompatible, I would also get a warning from CloudFormations/AppSync's API.

with that said, I'd be happy to hear your experience with using other targets (es6) if you have tried it.

Thanks for commenting!

Hey, thanks for the answer!

Recently I've been considering different approaches for my new typescript lambda projects and some of those considerations revolved around choices of commonjs / module project type, ES lib & build targets, node version, ts, prettier & eslint configurations and then compatibility of all of the above with DI, validation & testing libraries, CDK deployments etc. As you probably know, dealing with this stuff can push relatively sane person to the edge of insanity, so I may've been a bit sensitive about the topic when I saw "ESNEXT" recommendation in your article. So I'm sorry if I sounded hostile / attacky!

For now I was only considering AppSync as one of the options for new project we're working on within the company, so I just started playing with it and naturally landed in APPSYNC_JS, but before going through overview I went straight to compatibility and found this: docs.aws.amazon.com/appsync/latest/devguide/resol… and then your article which immediately got me triggered as something was off.

Nevertheless it seems like you're right, and since AWS is posting those sorts of examples we may assume it's recommended way, even though it may seem to potentially contradict their own documentation (at least to my understanding, I may not be expert enough to be the judge here).

Off topic curiosity: beside looking into AppSync I also started checking out VTL mapping for both AppSync & API Gateway and man- if you didn't see documentation wild west then this is the place, ton of undocumented behaviors & limitations which answers to can be found everywhere but official docs.

Thanks for clarifying and have a good day, Cheers!

Search Hashnode