tyson VS cdk-ecs-service-extensions

I have a similar view to yours: as soon as you need variables, imports, functions or any other type of logic ... the existing "data-only" formats break down. Over time people either invent new configuration languages that enable logic (i.e. cue or jsonnet), or they try to bolt-in some limited version of these primitives into their configuration.

My personal take is that at some point you are better of just using a full programming langugage like TypeScript. We created TySON https://github.com/jetpack-io/tyson to experiment with that idea.

Apparently "not depending on Node or V8" means depending on some random Go JS engine instead.

Author here. This is correct. I have used Pulumi and I love CDK. I think the models in Pulumi and CDK are both great, but they tend to be either too low level or too high level.

For example Pulumi has a `awsx.ecs.FargateService` class that can deploy a container to AWS Fargate, but the API is limited and you don't really have the capability to remix it into other scenarios. For example you have the capability to attach a load balancer to a service as ingress, but what if you want to attach an API Gateway, or just setup a Route53 record for direct public IP ingress?

CDK has a few more variations in what you can do but it tends to be even worse because it has class names like: `ApplicationLoadBalancedEc2Service` and `NetworkLoadBalancedFargateService`. Switching your infrastructure requires switching to an entirely different top level when you define your infrastructure.

What I am proposing with the extensions interface is that we build more a class inheritance style model, kind of like CSS, to let people mix in alternative behaviors, alternate configurations, or even attached resources in an additive way, onto the existing infrastructure as code model.

In the example prototype on Github you can see how this works: https://github.com/cdklabs/cdk-ecs-service-extensions

All types of mutations, from configuration mutations, to attached resources are just extensions that you can use the `ServiceDescription.add(Extension)` method to attach to your existing infrastructure, kind of like just layering on another CSS class onto your DOM element. I think for large and complex infrastructure this will be a more scalable, decouplable, and readable approach.