CDK for Terraform 0.18 reduces synthesization time
The newest CDKTF release cuts synthesization times for TypeScript, Python, and Java, drastically improving the user experience.
CDK for Terraform (CDKTF) lets you write HashiCorp Terraform configurations in your choice of TypeScript, Python, C#, Java, or Go, and still benefit from the full ecosystem of Terraform providers and modules. CDKTF reached general availability in August, 2022.
Today, we’re releasing CDKTF 0.18, which:
- Improves performance, drastically reducing synthesization time for TypeScript, Python, and Java
- Further improves the
cdktf convert
command, which translates HCL to TypeScript, Python, C#, Java, or Go
» Performance optimization
The newest CDKF release includes features and documents best practices for bringing down the synthesization time across all languages. You can see a summary of performance-related best practices in our documentation under Performance. All numbers shared below reference the synthesization (synth) time for the AWS example (Typescript / Python / Java / C# / Go).
» Reduced TypeScript synth time
Since CDKTF natively runs on TypeScript and doesn’t require language translation, it is the most performant language in terms of synth. However, we found that using star imports (e.g. import * from "@cdktf/cdktf-provider-aws"
) on the root level can slow down synth. This is primarily due to TypeScript importing the entire provider library in order to do type checking on it. For bigger providers like AWS, Google Cloud, or Microsoft Azure, this can result in synth times of around 30 seconds.
Since the release of CDKTF version 0.13, we support namespaces as a performance enhancement, and by switching to specific imports of the resources and data sources used (e.g. import { Instance } from "@cdktf/provider-aws/lib/instance"
), users can get this down to around 4 seconds. If users want further improvements, one option is to use TypeScript compilers such as swc
or tsx
that don’t do type checking, which can cut synthesization time to less than 1 second.
» JSII upgrades
We also upgraded the underlying JSII compiler and changed the way CDKTF uses JSII under the hood. Now all compiled languages (Python, Java, C#, Go) demonstrate performance improvements, including faster code execution. Behind the scenes, CDKTF uses JSII to translate TypeScript code into different languages. When a CDKTF project is run, a Node.js server is spun up that the target language talks to. Upon starting, the server needs to unpack, parse, and load all referenced JavaScript files. This process was slower than necessary, taking roughly 2 to 4 seconds and 1 second per provider/module. In CDKTF 0.18, we reduced the time to approximately 500ms and 100ms respectively, making the execution part of the process a lot faster.
» Reduced Python synth time
In Python, we noticed that the generated directory structure led to all submodules of a provider being imported at once, even if the import specified a specific submodule. This resulted in a lot of unnecessary parsing by the Python interpreter. CDKTF 0.18 fixes this problem, boosting performance from roughly 35 seconds for synthesization down to 2 seconds.
» Reduced Java synth time in Gradle
For Java, new CDKTF projects will default to using Gradle instead of Maven. We advise existing users to do the same. For existing projects, the fastest way to migrate is to use cdktf init
to create a new project, move existing files from the old project, and use cdktf provider add
to add the providers in use to a new project. In Gradle, iteration times for Java recompilation drop down to 30 seconds, compared to 3 minutes 30 seconds in Maven.
» Go performance improvement
CDKTF 0.18 also improves the time and resources cdktf get
takes in Go by removing the go build ./...
step that previously consumed a lot of resources and time when invoked on bigger providers.
» Further iteration on cdktf convert
With the release of CDKTF 0.16 in April, we announced a series of improvements to the cdktf convert
command, which allows users to translate their existing Terraform HCL code to a CDKTF-compatible language automatically. In July, we launched multi-language provider documentation in the Terraform Registry, adding code samples in TypeScript and Python for the AWS provider, the Terraform Cloud/Enterprise provider, and others.
The sequence of these announcements is no coincidence: The multi-language provider documentation is powered by the cdktf convert
command. As such, the CDKTF 0.18 release includes several improvements to convert
that make the translations into TypeScript and Python robust enough for the multi-language provider docs in the Terraform Registry. Check out the CDKTF 0.18 release notes for a full list of the improvements and bug fixes.
Our next goal for convert
is to make the translations into Java, C#, and Go robust enough to add those languages to the Terraform Registry. In the meantime, we are excited to announce that we have expanded the TypeScript and Python documentation for the AWS provider to include all resources, extending beyond the limited subset that we initially launched with. Check out our updated multi-language AWS provider docs.
» What happened to CDKTF 0.17?
Our last release blog post addressed CDKTF 0.16. On June 15, we released CDKTF 0.17. We did not make an announcement because version 0.17 did not include any new user-facing features (we were forced to do an emergency release with a breaking change, albeit one that does not affect most users, in order to maintain compatibility with version 4.67+ of the AWS provider). You can read more about the CDKTF 0.17 release and its impact in our upgrade guide.
The CDKTF 0.18 release includes the user-facing features that were previously planned for CDKTF 0.17.
» What's next for CDKTF?
The upcoming CDKTF 0.19 release is scheduled to include basic support for config-driven import, which was added in Terraform 1.5, as well as better support for refactoring, including state moving.
» Try CDK for Terraform
If you’re new to the project, these tutorials for CDK for Terraform are the best way to get started. You can dive deeper into our documentation with this overview of CDKTF.
Whether you’re still experimenting or actively using CDK for Terraform, we’d love to hear from you. Please file any bugs you encounter, let us know about your feature requests, and share your questions, thoughts, and experiences in the CDK for Terraform discussion forum.
Sign up for the latest HashiCorp news
More blog posts like this one
HCP Terraform adds run queue visibility and new ephemeral workspace features
HCP Terraform and Terraform Enterprise gain new features related to ephemeral workspaces along with run queue visibility for HCP Terraform specifically.
Automate AWS deployments with HCP Terraform and GitHub Actions
Learn how to use GitHub Actions to automate HCP Terraform operations.
Access AWS from HCP Terraform with OIDC federation
Securely access AWS from HCP Terraform using OIDC federation, eliminating the need to use access keys.