Hashicorp recently announced CDK for Terraform on AWS with CDKTF provider.

Lets take it for a test drive! Actually for a comparison test drive: how does development feel in CDKTF compared to AWS CDK native library?

I initialized cdktf project in VS Code, then added "aws-cdk-lib" dependency. Then I picked up a random resource, Route53 record. Then I've added child constructs into the stack. On the screenshot below is the result of both CDK applications side-by-side. 

First impression, looking at the construct annotations on the images below, Route53Record in CDKTF creates "aws_route53_record" resource which linked to external help site. The page describes the resource in HashiCorp Configuration Language (HCL). As a developer, I'd be curious what's that resource exactly for? We also noticed the mapping between configuration object is not strict, for example "zoneId" in CDKTF is "zone_id" in the HCL resource.

AWS CDK library does not expose such low level details. ARecord is a class which extends some other classes. The class properties provide interfaces for configuration options. 

Lets look more closely into classes configuration options. This is where the library abstractions will start to break for developers. The "name" is a just a string in CDKTF's Route53Record class with the link to Terraform documentation site about aws_route53_record "resource".

AWS CDK library properly annotates it as "The domain name for this record".

AWS CDK starts to shine when the configuration options have specific types. For example, the zone is not just a string as in CDKTF, but a particular type IHostedZone. Developers have to create const to define the zone correctly. There are few convenient methods in HostedZone class. It is pretty easy to find out which one should use. When developers write CDKTF, they will have no clue how to define zoneId, unless they research help sections of Terraform site.

Smashing types into strings is not a very good development experience for someone unfamiliar with Terraform syntax and resource definitions.

Next three images show how to define zone with types checking.

The same applies to the records property in CDKTF. It is "target" equivalent in AWS CDK. In CDKTF, records is a list of strings. Strings provide no context what kind of records they are. In the AWS CDK library, target has the type of RecordTarget class, which lists available options for the record target, including a particular AWS type of alias. Pretty hard to misconfigure ARecord options in AWS CDK.

Conclusion.

The CDKTF and CDK application classes look pretty similar; however, there are substantial differences in how libraries design, annotate, and abstract resources in the cloud. There is also almost no types enforcement in CDKTF, while AWS CDK requires typed properties. Static types in AWS CDK is a massive boost to productivity: developers do not have to guess what "string" means, or what options class constructor needs.

AWS CDK composes classes and interfaces much better as well. In CDKTF there is one class for this example: Route53Record. It extends cdktf.TerraformResource class and then maps everything to Terraform's aws_route53_record "resource."

In CDK, you will use ARecord, HostedZone, RecordTarget classes, and IHostedZone interface from the CDK library to create A record.