Ask HN: AWS cdk, serverless setup advice
3 comments
L3 constructs [0].
Define MyProjectLambda construct that handles common patterns, add methods for optional functionality.
[0] https://docs.aws.amazon.com/prescriptive-guidance/latest/aws...
Define MyProjectLambda construct that handles common patterns, add methods for optional functionality.
[0] https://docs.aws.amazon.com/prescriptive-guidance/latest/aws...
1 API Gateway + fat lambdas
Fat lambdas huh. For some reason I've always wanted lots of lambda's because of logs monitoring but yeah, having fat lambda's solves a lot of ergonomic issues I suppose.
- dynamodb - nodejs lambda functions - s3 - cdk to setup infra, attach lambda's to various resources
nearly all our features rely on the following "common/reuseable" existing code. This is thoroughly tested because they are reused in multiple projects. -> we have a core set of infra/lambda code that does common things like -> authorization/authentication/accounts - using auth0 behind the scenes - for user management -> billing - using a stripe setup. we have ddb table, webhooks and various lambda to support billing based on accounts above -> managing uploads - presigned and direct multipart/form-data uploads and saving metadata in dd -> creating and tracking jobs - via sqs -> have api as a service module that helps us track useage for api's being sold to public
For a typical project, we spin up the above existing infra Add custom infrastructure to do things specific to the project This typically involves -> adding an api gateway and attaching lambda handlers -> and so on.
My question is Which of you do something similar How do you organize reuseable code - do you create your own custom constructs library? Do you have one giant gateway that custom apis get attached to or you create new gateways to do whatever.