AWS CDK provider

[0xdevalias]

Describe the solution you'd like

Currently Amplify only supports direct CloudFormation as a provider, and does so by using JSON templates. I read somewhere that other providers can be implemented, and that a future goal is to support multiple providers. It would be great to have an AWS CDK provider, that constructs similar features, but in CDK code.

I feel like this would make it easier to implement new features in Amplify, leveraging common usecases and improvements (eg. asset upload, AWS SAM transformations, YAML output, etc)

Currently I wasn't able to find much of any information/documentation on what is required to implement a custom/new provider, so maybe documenting that/making it easier to discover would be useful as part of this also.

Describe alternatives you've considered

Using AWS CDK / SAM separately, and/or consuming externally generated resources through exports.

Additional context

See also: #160

[hassankhan]

Hi there, just adding my 2p,

In my (admittedly biased) opinion, the CDK would make it far easier to define stacks, while still allowing raw CloudFormation template generation. As it stands currently, to implement the CDK would require changes to each individual amplify-category-* package, specifically within their provider-utils subdirectories.

Converting to the CDK would have be a significant effort since each amplify-category-* package defines its own CloudFormation stack. Since the CDK can be used to synthesize raw CloudFormation templates, it would seem redundant to keep both the CDK stacks and CFN templates in source control.

Multiple Stacks:
aws-cdk expects that an "App" consists of one or more stacks, which fits in perfectly with how Amplify CLI has split features into separate stacks. However, currently the CDK uses cross-stack references instead of nested stacks - not sure how much of a problem this is in practical application (aside from the likely breakage of existing Amplify CLI-generated apps).

Custom Resources

It also becomes far easier to create and test custom resources. The only example I can think of right now is in amplify-category-analytics, where a custom resource for Pinpoint is created, but I'm sure there are other places where this would be equally useful.

Stack Diffing

The CDK provides a "diff" feature by using CloudFormation ChangeSets, this has the potential to move technical debt out of Amplify CLI. Alternatively, Amplify could format output from CDK to perhaps make it more user-friendly. Fixes #366.

Stack Deployment
Issues with rate-throttling like #705 are largely solved by the CDK team IIRC.

Asset Bundling

You can also take advantage of the built-in asset packaging functionality, or allows you to easily write your own. This would give users a way to package their code however they desire. Fixes #659.

Problems/Risks

With all the above said though, AWS-CDK isn't the most straightforward library/framework/kit(?) to integrate with/wrap around. Also, since it is currently still in pre-release, the serialization protocol that the CDK CLI uses is unstable (last I checked), which could introduce problems down the line.

---

Given that both Amplify and CDK are AWS projects, it would be great to see some dogfooding here. Both these products are HUGE for developer productivity in my opinion, and any wins with respect to maintenance will continue to pay off in the long run (for both Amplify maintainers and users).

[lielran]

any update on this one? any feedback from amplify/cdk teams?

[dsmrt]

First off, @hassankhan really nice break down.

To build off of this issue, I've worked enough with both amplify and cdk now be considering converting an app (which is currently in development) to using cdk instead of amplify's environment building. I need more flexibility which is more of a me problem than an amplify problem but I'm finding myself doing really tricky operations to get things to work like I need it to.

One thing I'd like to propose is, why can't both of these tools live separately but compliment each other better? This might be the easiest path forward.
Couple things to consider here:

• (reiterating a couple point from @hassankhan) Amplify/CDK team can create an amplify solution/pattern similar to aws-ecs-patterns. This proposed Amplify pattern would create the Amplify app/branches/etc with cloudformation. Asset support for resolvers and pipelines for AppSync would be awesome
• Decouple cloudformation template generation and deployment from the amplify cli. For my team this means:
  • Being able to generate the GraphQL typescript/javascript code (which I think we can currently do as long as we have the GraphQL schema).
  • Allow amplify mock to work with an app that's not completely controlled by the amplify cli. If you have any suggestions on how to make this currently work.
• Deployment could work completely thru cdk, at least, until the addition of the cdk provider makes sense.

[kmbro]

I'd love to see a cdk + amplify partnership/crossover/something in the near future. Love what has been said so far. Right now, I am starting another project and am going to use the cdk exclusively. I am finding I miss the way amplify made things easy for the initial setup of an app, specifically api + auth + lambda + dynamodb. If there were a few simple cdk stacks you could generate with amplify that would be really helpful.

[MattJColes]

+1

[lorengordon]

Would love to see this! I think it would also solve #3068 and #4800, because the generated cfn templates would not need to be committed to the repo.

[MontoyaAndres]

any update?