cuezel VS constructs

I played with a similar idea a while ago: https://github.com/ecordell/cuezel/ (cuezel as in: "Bazel but with CUE"), but I was never sure that what I was doing was in the spirit of CUE.

CUE pushes nondeterminism into "_tool.cue"[0] files that are allowed to do things like IO and run external processes. Tool files scratch a similar itch to Makefiles, but they lack an integrated plugin system like Bazel (hence why I played with the idea of CUE + Bazel).

With Dagger you seem to be restricted to the set of things that the dagger tool can interpret just with like my Cuezel tool you are limited to what I happened to implement.

In CUE `_tool` files you are also limited to the set of things that the tool builtins provide, but the difference is that you know that the rest of the CUE program is deterministic/pure (everything not in a _tool file).

There's clearly value in tooling that reads CUE definitions, and dagger is the first commercial interest in CUE that I've seen, which is exciting.

But I'm most interested in some CUE-interpreter meta-tool that would allow you to import cue definitions + their interpreters and version them together, but for use in `_tool` files to keep the delineation clear. Maybe this is where dagger is heading? (if so it wasn't clear from the docs)

[0]: https://pkg.go.dev/cuelang.org/[email protected]/pkg/tool

To "meet developers where they are" is a beautiful tenet of AWS, and of the CDK, and inspired us to create awesome technology such as JSII and constructs.

I agree with constructs, I recommend using both (article mentions). Create your template, you might have various CDK constructs (community, AWS, personal), the template will produce a full project how you / your org want it. This might include your github actions for linting, cdk synth, testing, deployment etc. Application source (Lambda, API, container etc). Anyone in your team or external should be able to take that template and produce a project that is the same.

Have you heard of or explored https://github.com/aws/constructs (related: https://github.com/aws/jsii and https://github.com/aws/aws-cdk)?

This is what CDK uses for declarative modeling, but gives the opportunity to use languages/tooling that most devs are already familiar with. CDK8s already uses it as a replacement for yaml (technically, the yaml becomes an implementation detail rather than actually replaced)

All CDKs are based on Amazon's Constructs, (which also uses projen). They come with a CLI and Development Kit (API). In short, you set up an Object in code and then synthesize the representation to disk. This opens up the full power of programming languages. If you are sick of the issues with terraform, CloudFormation Templates, troposphere, Azure Blue Prints, or the like then this is for you.