Thank you for your comment RiyaSree I currently have no plan to extend this project as it is. It was more meant to be a way of learning new things, and a starting point for people who want to build something similar. Every company/user will have their own needs, and it would be hard to have a solution that fits every use case. Feel free to copy or fork this project and extend it to your own needs, though.

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). https://docs.aws.amazon.com/appsync/latest/devguide/resolver-reference-overview-js.html#additional-utilities 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!

It's hard to tell without any more context / code. when does this error show up?

The limit is per region per account. If you ever need more than 25 APIs for a project, in practice, they will often be for several micro-services (even if for the same app) and I would highly consider separating them into different AWS accounts.

I don't think this is possible. At least not at this time. Each API has its own log group by default, and you cannot change it. The only thing you can do is attach the same Lambda to each individual log group.

Hi, I have never seen that error. The first thing I would do is to double-check what code was generated and if it looks correct. I might be wrong, but "Unable to transform the template" looks like a VTL error. Make sure you use the code property in the CDK and enable JS runtime.

I would not say it's a replacement. They are slightly different conceptually, although you can achieve similar things with both. DynamoDB stream allows you to consume Change Data Capture (CDC) events and process them. EventBridge is an event broker. You can use it to achieve the pub/sub pattern and decouple the event emitter and subscribers.

Thank you for your feedback. I'll try to update the articles and include a full example.

Yes. From your AWS account (the "safe" side), you allow GithubActions jobs to assume the given role. For that, you add an identity provider (Github Actions is the id provider) and you allow GA "users" to assume a role. When a job runs, it uses the ID provider to "authenticate", and assume the role. It works like "login with Twitter", except it's with Github Actions. The job already has a GA token. It uses it to "log into AWS" and assume the role. The key part is really token.actions.githubusercontent.com:sub . Without that, ANY repo on GitHub would be able to authenticate and assume the role.**

Do you mean without denormalizing an id attribute? Yes, it would still work. But keep in mind that it would be easier to return from the API if it comes pre-denormalized.