Implement constructs extensions

[fredericbarthelet]

Fixes #191

[t-richard]

I love the idea!

I don't have a clear idea of what the ideal solution would be but here are some thoughts to get the discussion started around this.

Do we want to expose Cloudformation properties? Or would it be possible to expose underlying CDK properties? I guess the latter is harder because not everything is a property, some things need to be created as separate objects or as method calls.

From a Lift developer perspective, wouldn't it be more friendly to have a generic way to expose and merge config built in the provider instead of each individual construct?

Would this be as resources.extensions in Serverless framework? I now that in sls, the extensions are only replacing keys at the first level. This would be problematic for Lift as some Cloudformation resources are poorly designed on AWS side like Cloudfront distributions that have a single DistributionConfig key in properties.
Overriding the static website or server-side website would get way harder as you would need to redifine every property to make it work with undermines the benefits of using Lift.

[fredericbarthelet]

Would this be as resources.extensions in Serverless framework? I now that in sls, the extensions are only replacing keys at the first level. This would be problematic for Lift as some Cloudformation resources are poorly designed on AWS side like Cloudfront distributions that have a single DistributionConfig key in properties. Overriding the static website or server-side website would get way harder as you would need to redifine every property to make it work with undermines the benefits of using Lift.

Thanks for your feedback @t-richard :) I made Lift's API to provide extensions entry point as simple to enrich as possible. I now completed first version of this PR for you and @mnapoli to have a deeper look on the internals. Additional entry point can easily be added for the extensions as use cases pop up.

For exemple, if you want to provide for Lift users at later stage an option to extend the OriginRequestPolicy of the underlying CloudFormation resource within server-side-website construct, you'll "just" have to add the following line in the extend method of the construct :

    extend(): Record<string, CfnResource> {
        return {
            distribution: this.distribution.node.defaultChild as CfnDistribution,
            originRequestPolicy: this.originRequestPolicy.node.defaultChild a CfnCachePolicy
        };
    }

More complex selector that the defaultChild of each CDK node can be used to reference the underlying in depth resources of the CloudFormation template. Would welcome any PR in a second stage implementing those to ensure no extensions requires a whole bunch of Lift best practice to be reimplemented manually ;)

[mnapoli]

That looks awesome, and the docs too!

Thanks 🎉 @fredericbarthelet

[piolet]

hello,

may I ask a question, more than a comment?
For this type of builder, we will also create an S3 bucket, will it be possible to adjust it, like the "storage" builder, or will we only be able to adjust the distribution?

[fredericbarthelet]

Absolutely possible :) I'll merge this one, if you want to provide a PR on the basis of this new code base to implement the storage extension on this construct, you're welcome to :)

[piolet]

I would love to, but I can't compile the project properly, nor can I run the unit tests without errors on my side (on the branch master). So it's hard to try implementations :/