Hi All,
We are in a process to adopt CDKTF w/ Typescript as a IaC Practise at our organisation.
However there is one fundamental confusion I have right now, if we should be using the standard Configuration Json needed by CDKTF entities, or write a custom interface which takes less number of inputs and then generates the required Configuration Json - however the later will increase the blast radius scope to a very high amount, that an error in the interfact can cause issues across infrastructure.
Hey there,
I am not 100% certain I got your question correctly, so I’ll try to sum it up first:
You wonder if building abstractions on top of provider bindings might lead to problems down the road with consumers of these abstractions as you introduce breaking changes and unexpected behaviour could occur.
In general we advise to create custom bindings that represent a logical unit within the work you are doing, this is one of the advantages of the CDK that abstractions are easy to build and extend.
I can understand the concern with breaking changes, the solution here is dependant on your setup and similar to e.g. an API client you would write. If you are in a mono-repo situation the type system should hint you towards problems with apps using your foundational package early on in the development process. In a multi-repo setup you’d probably want to release the abstractions as an artifact to npm or a similar tool for others to consume. This would allow them to pin the version they are tested against, ensuring no unforeseen changes.
Speaking of which, as Terraform does the underlying work for CDKTF you are going to get a plan when deploying the new version that informs you of all changes that will be made, so as long as you keep an eye on that there is little risk for unforeseen changes.
I’d also like to point you towards some resources on this topic in general: