Higher level Constructs

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave “+1” or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Currently there’s only 1:1 mappings for most TF providers, and this is an awesome thing to have. But the big selling point for CDK(in my eyes) is that there’s higher level constructs which reduce all the bits and pieces you have to think about when using terraform or cloudformation, let’s call the 1:1 mappings L1 constructs and anything above that L2.

This would involve having a higher level construct for highly used resources. Think of adding a L2 construct for AWS Lambda, a loadbalanced AWS ECS cluster etc.

Basically supercharged terraform modules 😃

Cool, how would this look like?

Consider the following Lambda function setup:

// rest of the stuff is 
const lambdaRolePolicy = { // this could be typed!
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
};
const role = new aws.iam.IamRole(this, "lambda-exec", {
  name: `learn-cdktf-${name}-${pet.id}`,
  assumeRolePolicy: JSON.stringify(lambdaRolePolicy)
});

const lambdaFunc = new aws.lambdafunction.LambdaFunction(this, "learn-cdktf-lambda", {
  functionName: `learn-cdktf-${name}-${pet.id}`,
  s3Bucket: bucket.bucket,
  s3Key: lambdaArchive.key,
  handler: config.handler,
  runtime: config.runtime, // this could be a nice enum
  role: role.arn
});

This requires a bunch of stuff I don’t want to worry about when developing a simple lambda function (CDKTF could lighten this!)

const lambdaFunc = new LambdaFunction(this, "l2-lambda-func", {
  functionName: 'foobar',
  // role can be entirely omitted, just generate one behind the scenes that's assumed by lambda principal
  runtime: aws.Lambda.Runtimes.DOTNETCORE3.1,
  code: new AssetCode("./code.zip"),
  // for the rest provide sensible defaults, use nullable features where possible to indicate a required property etc
});

I’m more than happy to spend some time on this if this is something we actually want

References

There’s many, but the start would be removing all these hardcoded strings which could be in enums across most resources and eliminating the size of code needed for highly used resources by adding sensible defaults and 1st class ‘modules’. https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3.BucketAccessControl.html https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_lambda.RuntimeFamily.html https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3.RedirectProtocol.html

props like autoDeleteObjects on S3 bucketswould be a big boon https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3.Bucket.html#construct-props. There’s countless ways we could make the library nicer to work with, which results in cleaner code for everyone.

[ansgarm]

Ah, I see! Sounds like you have some slightly different thing in mind. Please let me know if I understood you correctly, but instead of only having L2/L3 abstractions for each single cloud provider, you’d rather build a shared L3 first (e.g. an L3 construct for a “hosted static website”) and then have different implementations based on the cloud provider (i.e. implementations for that abstraction). Is that right? If yes, we could rephrase this issue’s title instead of closing it 👍

We also had some discussions about this in the team in the past. I personally am quite torn about it, as I fear that different cloud providers have too different ways of approaching granting access to resources. So an abstraction like bucket.grantRead() might work with AWS IAM but could become leaky for other cloud providers that have e.g. some group based access model (I think Google does, but I’m not sure). But there might of course still be solutions to this problem and it could be possible to find a model that is not too leaky while supporting multiple patterns of “granting access”. I also remember that @DanielMSchmidt also had some ideas around this and is less skeptic about such shared layers than I am 😁

The CONTRIBUTING.md mostly covers PRs to this repo, so feel free to just go ahead with a quick repo 👍 Such a first draft would be much appreciated as it would serve as a good base for further discussions. However, of course we can’t promise you that we’ll adopt it.

Have you seen the cdktf-plus package? @skorfmann started this some time ago to help with common boilerplate when deploying e.g. AWS lambda functions using CDKTF. It might serve as a good starting point about how to build a construct library.

[github-actions[bot]]

Hi there! 👋 We haven’t heard from you in 30 days and would like to know if the problem has been resolved or if you still need help. If we don’t hear from you before then, I’ll auto-close this issue in 30 days.