Skip to content

Commit 9a71d91

Browse files
Torbjorn van Heeswijckkai-nguyen-aligent
andauthored
Migrate template to an AWS CDK based setup
* Increment root package version, move to node 22, Nx 21 and new typescript setup * Add core CDK application and service generator * Add CDK migration notes, version and alias resources, lambda defaults, STAGE tag * Constructs, aspects, injectors to standardise development in cdk-utils * Use mjs format for everything * Include store-parameters package for SSM parameter management --------- Co-authored-by: KaiNguyen <108910975+kai-nguyen-aligent@users.noreply.github.com>
1 parent 229732e commit 9a71d91

158 files changed

Lines changed: 9579 additions & 11235 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

.git-hooks/pre-commit

Lines changed: 28 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -6,20 +6,40 @@
66
export NVM_DIR="$HOME/.nvm"
77
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
88

9-
# This take the current active node version you want to verify the hook
10-
export NVM_DIR="$HOME/.nvm"
11-
a=$(nvm current)
12-
13-
export PATH="$NVM_DIR/versions/node/$a/bin:$PATH"
14-
159
# Define colours for nicer CLI output
1610
RED="\033[1;31m"
1711
GREEN="\033[1;32m"
1812
NO_COLOUR="\033[0m"
1913

20-
echo -e "${GREEN} Executing git hook $0 $@ ${NO_COLOUR}"
14+
echo -e "${GREEN}Executing git hook $0 $@${NO_COLOUR}"
15+
16+
# Use the current Node version explicitly
17+
nvm use
18+
19+
# Get the list of staged changes
20+
STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM)
21+
22+
# Exclude files that shouldn't trigger pre-commit checks
23+
# This is done here because `nx affected` doesn't look at task inputs
24+
# when determining if a project is affected
25+
EXCLUDED_FILES_REGEX='.*\.md$' # Ignore markdown files
26+
EXCLUDED_FILES_REGEX+='|.*\/step-functions\/.*\.(yml|yaml)$' # Ignore step function yaml files
27+
EXCLUDED_FILES_REGEX+='|^\/?([^\/]*)$' # Ignore all root-level files
28+
AFFECTED_FILES=$(echo "$STAGED_FILES" | \
29+
grep -vE "$EXCLUDED_FILES_REGEX" | \
30+
paste -sd,)
31+
32+
echo -e "${GREEN}\nAffected files: $AFFECTED_FILES\n${NO_COLOUR}"
33+
34+
# Exit early if there are no affected files
35+
if [ -z "$AFFECTED_FILES" ]; then
36+
echo -e "${GREEN}No affected files found. Exiting pre-commit hook.${NO_COLOUR}"
37+
exit 0
38+
fi
2139

22-
commands=("npx nx affected -t lint, typecheck --parallel=3" "npx nx affected:test --coverage")
40+
# Prepare the affected commands for static analysis targets
41+
AFFECTED_COMMAND="yarn nx affected --files=$AFFECTED_FILES --nxBail --tui=false"
42+
commands=("$AFFECTED_COMMAND -t lint typecheck --parallel=3", "$AFFECTED_COMMAND -t test --configuration coverage")
2343
failures=()
2444

2545
# Loop over commands, execute and push failure message if we see one

.github/workflows/package.yml

Lines changed: 10 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -12,9 +12,12 @@ jobs:
1212
deploy:
1313
name: Test package building
1414
runs-on: ubuntu-latest
15+
env:
16+
# Generating an Nx library will cause a failure if this is enabled
17+
YARN_ENABLE_IMMUTABLE_INSTALLS: 0
1518
strategy:
1619
matrix:
17-
node-version: [20.18]
20+
node-version: [22.14]
1821
steps:
1922
- name: Checkout repository
2023
uses: actions/checkout@v4
@@ -29,13 +32,13 @@ jobs:
2932
cache: yarn
3033

3134
- name: Install dependencies
32-
run: yarn install --immutable
35+
run: yarn install
3336

3437
- name: Generate test library
35-
run: npx nx g library test-lib --directory=libs/test-lib --unitTestRunner=none
38+
run: yarn nx g library test-lib --directory=libs/test-lib --unitTestRunner=none
3639

3740
- name: Generate test app
38-
run: npx nx g service test-app
41+
run: yarn nx g service test-app --type=general
3942

4043
# The next 2 lines are needed for nx affected to work when CI is running on a PR
4144
- name: Set base SHA to origin/main
@@ -45,10 +48,10 @@ jobs:
4548
run: git fetch
4649

4750
- name: Run tests
48-
run: npx nx affected -t lint, test, build --parallel=3 --base=origin/main
51+
run: yarn nx affected -t lint, typecheck, build --parallel=3 --base=origin/main
4952

5053
- name: Remove test library
51-
run: npx nx g rm test-lib
54+
run: yarn nx g rm @aligent/test-lib
5255

5356
- name: Remove test app
54-
run: npx nx g rm test-app
57+
run: yarn nx g rm @services/test-app

.gitignore

Lines changed: 7 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2,12 +2,13 @@
22

33
# environment
44
*.env
5+
*.env*.csv
6+
!.env.example.csv
57

68
# compiled output
79
dist
810
tmp
9-
/out-tsc
10-
.serverless
11+
out-tsc
1112
.build
1213

1314
# dependencies
@@ -58,3 +59,7 @@ Thumbs.db
5859
# Vite temporary config files
5960
vite.config.*.timestamp*
6061
vitest.config.*.timestamp*
62+
63+
# CDK asset staging directory
64+
.cdk.staging
65+
cdk.out

.nvmrc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1 @@
1-
v20.18
1+
v22.14.0

.vscode/extensions.json

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,6 +3,9 @@
33
"nrwl.angular-console",
44
"esbenp.prettier-vscode",
55
"dbaeumer.vscode-eslint",
6-
"editorconfig.editorconfig"
6+
"editorconfig.editorconfig",
7+
"amazonwebservices.aws-toolkit-vscode",
8+
"usernamehw.errorlens",
9+
"yoavbls.pretty-ts-errors"
710
]
811
}

CLAUDE.md

Lines changed: 155 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,155 @@
1+
# CLAUDE.md
2+
3+
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
4+
5+
## Essential Commands
6+
7+
### Testing
8+
9+
- **Run tests for affected projects**: `yarn test`
10+
- **Run tests for all projects**: `yarn test:all`
11+
- **Run a single test file**: `npx vitest run path/to/test.spec.ts`
12+
- **Run tests in watch mode**: `npx vitest watch`
13+
- **Run tests for specific project**: `npx nx test @libs/cdk-utils`
14+
- **Run specific test file with Nx**: `npx nx test @libs/cdk-utils -- path/to/test.spec.ts`
15+
16+
### Code Quality
17+
18+
- **Lint affected projects**: `yarn lint`
19+
- **Lint all projects**: `yarn lint:all`
20+
- **Type check affected projects**: `yarn typecheck`
21+
- **Type check all projects**: `yarn typecheck:all`
22+
23+
### Service Management
24+
25+
- **Generate new service**: `npx nx g service <service-name>`
26+
- **Generate notification service**: `npx nx g service <service-name> notification`
27+
- **Deploy service to AWS**: `npx nx deploy <service-name> -- -s <stage> --aws-profile <profile>`
28+
- **Remove service from AWS**: `npx nx run <service-name>:remove -- -s <stage> --aws-profile <profile>`
29+
30+
### CDK Deployment
31+
32+
- **Deploy all stacks**: `cd applications/core && cdk deploy`
33+
- **Deploy staging stacks**: `cd applications/core && cdk deploy stg/**`
34+
- **Deploy production stacks**: `cd applications/core && cdk deploy prd/**`
35+
- **View CDK diff**: `cd applications/core && cdk diff`
36+
37+
### API Client Generation
38+
39+
- **Generate typed API client**: `npx nx g client <client-name>`
40+
41+
## Architecture Overview
42+
43+
This is an AWS microservices template using:
44+
45+
- **Nx monorepo** structure with services in `services/` and libraries in `libs/`
46+
- **AWS CDK v2** for infrastructure as code (recently migrated from Serverless Framework)
47+
- **TypeScript** with strict type checking extending @aligent/ts-code-standards
48+
- **Node.js 22.14.0** runtime
49+
50+
### Key Architecture Patterns
51+
52+
1. **Service-Based Architecture**
53+
54+
- Each service is a separate CDK Stack defined in `services/<service-name>/src/index.ts`
55+
- Services export a Stack class that extends `aws-cdk-lib.Stack`
56+
- Services are imported and instantiated in `ApplicationStage` inside `applications/core/bin/main.ts`
57+
58+
2. **CDK Application Structure**
59+
60+
- Entry point: `applications/core/bin/main.ts` creates CDK App and stages
61+
- Stages (dev/stg/prd) are created as ApplicationStage instances directly in `main.ts`
62+
- Stage-specific configuration is applied via property injectors and aspects
63+
- Each stage automatically configures resources based on deployment environment
64+
65+
3. **Lambda and Step Functions**
66+
67+
- Lambda functions are in `services/<service>/src/lambda/`
68+
- Step Functions use YAML definitions in `services/<service>/src/step-functions/`
69+
- Shared constructs in `services/<service>/src/lib/constructs/`
70+
- Step Functions use JSONata for output transformations
71+
- Automatic versioning and aliasing applied via VersionFunctionsAspect
72+
- Stage-specific configuration applied via property injectors
73+
74+
4. **Property Injection Architecture**
75+
76+
- Configuration-based defaults applied via property injectors:
77+
- **NodeJsFunctionDefaultsInjector**: Bundling configuration (sourceMap, esm, minify)
78+
- **LogGroupDefaultsInjector**: Duration-based retention (SHORT/MEDIUM/LONG)
79+
- **StepFunctionDefaultsInjector**: Automatic logging for EXPRESS workflows
80+
- **BucketDefaultsInjector**: Auto-cleanup policies for S3 buckets
81+
- Cross-cutting concerns handled by aspects (VersionFunctionsAspect for automatic versioning)
82+
- Configuration can be customized per stage or globally
83+
- Uses CDK's built-in property injection system - no custom constructs needed
84+
85+
5. **CDK Constructs and Utilities**
86+
87+
- **S3Bucket**: Lifecycle management with duration-based rules (SHORT/MEDIUM/LONG/PERMANENT)
88+
- **SsmParameterGroup**: Abstract class for grouping and managing SSM parameters
89+
- **StepFunctionFromFile**: Load Step Function definitions from YAML/JSON files
90+
91+
6. **Testing Strategy**
92+
- Vitest for unit testing with coverage reports
93+
- Test files colocated with source files as `*.spec.ts` or `*.test.ts`
94+
- Workspace-level Vitest configuration in `vitest.workspace.ts`
95+
96+
## Important Context
97+
98+
### CDK Migration Notes
99+
100+
- Project migrated from Serverless Framework to CDK using property injection pattern
101+
- CDK construct IDs are critical - changing them will replace resources
102+
- Lambda versions and aliases are automatically created via VersionFunctionsAspect
103+
- Step Functions use `LambdaInvoke` resource with automatic retry blocks
104+
- Task outputs are nested in `Payload` property - use JSONata to transform
105+
- Stage-specific resource configuration handled by property injectors
106+
107+
### Configuration
108+
109+
- Update brand name in `nx.json` generators section before first use
110+
- Package name in `package.json` should follow `@<brand>-int/integrations` format
111+
- Services are tagged with STAGE and SERVICE tags automatically
112+
113+
### Development Workflow
114+
115+
1. Always run lint and type checks before committing
116+
2. Use Nx affected commands to optimize CI/CD performance
117+
3. Follow existing code patterns and conventions in the codebase
118+
4. Check `CDK-MIGRATION-NOTES.md` for CDK-specific guidance
119+
120+
## AI Helpers
121+
122+
The `docs/ai-helpers/` folder contains documentation templates to assist AI code assistants in creating consistent and comprehensive documentation:
123+
124+
### Recommended MCP Servers
125+
126+
When using Claude Code or other MCP-compatible tools, the following MCP servers are recommended for this repository:
127+
128+
- **context7**: Provides up-to-date documentation for libraries and frameworks
129+
- **eslint**: Enables linting capabilities for code quality checks
130+
- **nx**: Offers Nx-specific commands and workspace insights
131+
132+
These servers should be used when available to enhance development capabilities.
133+
134+
### Available Templates
135+
136+
- **`APPLICATION_ARCHITECTURE_FORMAT.md`**: Template for creating comprehensive architecture diagrams for AWS CDK services
137+
- Provides guidelines for analyzing CDK application structure
138+
- Includes Mermaid diagram formats with consistent color palettes
139+
- Shows how to map Step Function workflows and Lambda functions
140+
- Contains common architectural patterns and best practices
141+
142+
- **`SERVICE_README_FORMAT.md`**: Template for creating service-specific README documentation
143+
- Standardized format for service documentation
144+
- Context diagram template showing external system interactions
145+
- Sections for workflows, critical information, and operational details
146+
- Consistent color palette for system visualization
147+
148+
### When to Use
149+
150+
Reference these templates when:
151+
- Creating new architecture documentation (`ARCHITECTURE.md`)
152+
- Documenting a new service with a README
153+
- Updating existing service documentation
154+
- Generating visual representations of service interactions
155+
- Ensuring consistency across all service documentation

0 commit comments

Comments
 (0)