[RFC] Deploy any CDK construct

[fredericbarthelet]

This discussion aims at uniting attempts at making a Lift Construct deploying any CDK construct.

Instead of creating a Lift construct that allows importing any CDK construct, this PR brings support for 3rd party Lift constructs.

This allows developers to use any CDK construct, but also to add Lift features, like:

construct outputs
construct variables
automatic IAM permissions
custom commands
etc.

Previous issues/PR regarding this topic :

• [RFC] Deploy any CDK construct #23
• [RFC] Deploy any CDK construct | v2 #52

[GuillaumeLagrange]

With @CorentinDoue, we would love to be able to contribute to the subject.

Our pipedream is seemless integration between CDK and Serverless framework so that nobody has to manually write Cloudformation anymore.
Here is our plan after a brainstorming session, we would absolutely love to get input from anyone.

• STEP 1: Define a customCdk Lift construct to allow instantiating arbitrary CDK constructs

  • Parameters: path to a file which exports a CDK construct
    • Bonus: support importing directly from a library
  • Inject it in the serverless resources key

  Pain points/uncertainties:

  • Dynamic import and TS compilation from a path
  • Scan the construct to detect the need for the CDK bootstrap stack, and throw an error if the CDK construct cannot be deployed with serverless framework.
    • We want to limit oursevles to using CDK as a cloudformation generation tool, so that we can easily remain compatible with how serverless framework deploys its resources.

  Benefits:

  • Enable to easily define extra resources with CDK instead of using resources key in serverless.yml

• STEP 2: Define a customLift lift construct to allow instantiating arbitrary Lift construct.

  Benefits:

  • Parameters: path to a file which exports a Lift construct
  • Instanciate the custom construct within Lift to be able to access:

    • the following methods:

        /**
         * Values shown in the CLI output.
         */
        outputs?():Record<string, () =>Promise<string|undefined>>;
        
        /**
         * serverless.yml variables
         */
        variables?():Record<string,unknown>;
        
        /**
         * Post-CloudFormation deployment
         */
        postDeploy?():Promise<void>;
        
        /**
         * Pre-CloudFormation deletion
         */
        preRemove?():Promise<void>;
        
        /**
         * IAM permissions to add to Lambda functions of the stack
         */
        permissions?(): PolicyStatement[];
      

    • the AwsProvider param and getLambdaLogicalId utils etc

  • Enable sharing Lift constructs through libraries

• STEP 3: Enhance the interface beween lift and serverless framework to be able to access the whole serverless configuration object within Lift constructs.

  Benefits:

  • Be able to use elements provided by the serverless framework directly in the Lift construct (mainly lambdas and api gateway)

• STEP 4: Enhance CDK/Serverless integration to seemlessly access resources from serverless in cdk and vice versa

  Benefits:

  • Access lambda from serverless as CDK constructs
  • Make CDK and serverless play nice when adding api gateway resources/methods in CDK

We opened a draft PR to illustrate how we would go forward on the subject if you guys want to have a look! #183