serverless VS lift

I don't know any tutorials that cover all of these, but check out: https://cdkpatterns.com/ for 1) https://docs.aws.amazon.com/cdk/v2/guide/cdk_pipeline.html for 2) 3) and 5) https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-cdk-testing.html for 4)

I would like to see re-useable design patterns advocated similar to the terraform/terragrunt modules concepts. Encouraging pulumi.ComponentResource definitions multi environment structure, best practices. The cdk guys have something similar https://cdkpatterns.com/.

While writing this post, the four stacks combined are 129 lines of source code. With the help of the CDK Constructs that are being used this translates to over 1k lines of code in CloudFormation. We are only using L2 constructs here – there is way more constructs available that you can use in the Constructs Hub and also a lot of guidance regarding the usage of CDK over at CDKPatterns.

I use the "Lambda-lith" pattern, primarily because I am using Rust and deploying via CI/CD (codepipeline).

Here is a read of common lambda design pattern https://github.com/cdk-patterns/serverless/blob/main/the-lambda-trilogy/README.md

Level 3 constructs are opinionated units of reusable code which often deliver a service. Open source level 3 constructs are available from AWS Solutions Constructs - an extension to the CDK, CDK Patterns - a library of well-architected patterns, Construct Hub - a library of open-source constructs and some even come out of the box with the CDK - these are appended with 'patterns' to make them identifiable. Two examples are shown below:

The template utilizes the lift plugin to leverage AWS CDK and expand Serverless' functions to avoid all the yak-shaving at the beginning. One can always tweak the parameters afterward, be it from the serverless.yml configuration file or directly from the AWS console.

Such implementation opens up a lot of new possibilities: a functionless RESTful API where the only code is configuration-only IaC is not out of reach anymore and can help team achieve cheaper, more robust code base with minimal efforts. Such implementation is currently under discussion within Lift project where your feedbacks on the implementation are highly valued.

Not yet, we're considering this: https://github.com/getlift/lift/pull/52 Any feedback on this is appreciated, ideally in the pull request -> we use that to measure interest. We try to judge which features to implement based on community feedback.