AWS CDK Infrastructure
Relevant source files
The following files were used as context for generating this wiki page:The AWS Cloud Development Kit (CDK) is used to define and provision the cloud infrastructure for the Nucleus project. The infrastructure code, located in the deployment/ directory, is written in TypeScript and manages various components of the application, including the backend server, serverless functions, and potentially the client and database layers. This approach allows for repeatable and version-controlled infrastructure deployment.
The overall project is a monorepo, and the deployment/ directory is a dedicated workspace for managing the cloud resources. The CDK setup is designed to be modular, with different parts of the application infrastructure likely separated into different stacks. The documentation suggests deployment targets such as Amazon EC2 and ECS, which are provisioned through this CDK setup.
Sources: WARP.md, deployment/README.md, deployment/package.json
Project Setup and Dependencies
The CDK project is configured as a standard TypeScript project. The deployment/package.json file lists the core dependencies and scripts required to synthesize and deploy the AWS infrastructure.
Sources: deployment/package.json
Key Dependencies
| Package | Version | Description |
|---|---|---|
aws-cdk | 2.116.1 | The AWS CDK command-line interface (CLI). |
aws-cdk-lib | 2.116.1 | The AWS CDK Construct Library. |
constructs | ^10.0.0 | Core programming model for the CDK. |
typescript | ~5.3.3 | Language used for defining infrastructure. |
ts-node | ^10.9.2 | Executes TypeScript files for the CDK. |
jest | ^29.7.0 | Testing framework for the CDK code. |
Sources: deployment/package.json:15-28
CDK Scripts
The scripts section in package.json defines how to interact with the CDK project:
| Script | Command | Description |
|---|---|---|
build | tsc | Compiles the TypeScript code to JavaScript. |
watch | tsc -w | Watches for file changes and recompiles. |
test | jest | Runs tests for the infrastructure code. |
cdk | cdk | Executes AWS CDK commands (e.g., synth, deploy). |
Sources: deployment/package.json:8-13
Infrastructure Stacks
The infrastructure is broken down into multiple stacks, each responsible for a specific part of the application. The file structure suggests stacks for the client, static client, server, and database.
This diagram illustrates the conceptual structure of the CDK application, with a main app instantiating various nested stacks.
Client Stacks
There are configurations for both a dynamic client and a static client, located in deployment/cdk/client/ and deployment/cdk/staticClient/ respectively. The cdk.json file in each directory specifies stack.ts as the entry point for deployment, which is executed using ts-node.
Sources: deployment/cdk/client/cdk.json:2, deployment/cdk/staticClient/cdk.json:2
Server Stack: Serverless Functions
A concrete example of the backend infrastructure is the PlanLambdaFunctions nested stack, which defines a set of serverless functions and their corresponding API Gateway endpoints under the /plan resource path.
Sources: deployment/cdk/server/v2/planLambdaFunctions.ts
API Gateway and Lambda Integration
The PlanLambdaFunctions class creates an API Gateway resource /plan and attaches several Lambda functions to it, each handling a specific action. All endpoints are configured with POST methods and also support OPTIONS for CORS preflight requests.
This diagram shows the API Gateway resource structure for the /plan endpoint and its integration with various Lambda functions.
Lambda Function Configuration
All functions within the PlanLambdaFunctions stack share a common configuration.
| Property | Value | Description |
|---|---|---|
runtime | lambda.Runtime.NODEJS_20_X | Specifies the Node.js 20.x runtime environment. |
timeout | Duration.minutes(defaults.timeout) | Sets the function timeout, value is imported from a config file. |
environment | props.lambdaEnvVars | Environment variables passed down from the parent stack. |
logRetention | RetentionDays.ONE_WEEK | CloudWatch logs are retained for one week. |
handler | index.handler | The entry point handler within the function code. |
code | lambda.Code.fromAsset(...) | The source code is packaged from a local dist directory. |
Sources: deployment/cdk/server/v2/planLambdaFunctions.ts:16-21
The following code snippet shows the definition for the getPlanFunction and its integration with API Gateway. The pattern is repeated for all other functions in the stack.
// File: deployment/cdk/server/v2/planLambdaFunctions.ts
const planEndpoint = props.api.addResource("plan");
const getResource = planEndpoint.addResource("get");
const getFunction = new lambda.Function(this, "GetPlanFunction", {
handler: "index.handler",
functionName: generateFunctionName("getPlanFunction", props.environment),
code: lambda.Code.fromAsset(path.join(__dirname, basePath + "get/dist")),
...nodeRuntimeFunctionProps
});
getResource.addMethod("POST", new gateway.LambdaIntegration(getFunction));
Sources: deployment/cdk/server/v2/planLambdaFunctions.ts:22-31