CDK app scaffolded with StorageStack, ApiStack, and ConversionStack; stack split separates concerns
dropthejase built the infra foundation as a CDK app with a stage helper and three independently deployable stacks. The stack split is the most reusable design decision here - each stack owns one concern with cross-stack values passed via CDK outputs or constructor props, not direct construct references.
StorageStack provisions two S3 buckets (docs, private + CORS; frontend, private) and a CloudFront distribution with OAC pointing at the frontend bucket, with a 404→200 SPA fallback. The CORS allowedOrigins starts as ['*'] and is later locked to the CloudFront domain.
ApiStack creates a Secrets Manager secret for Supabase credentials, an API Lambda IAM role with S3 read/write and scoped Bedrock model ARNs, a REST API Gateway with a Lambda Token authorizer on all routes, and Lambda + Gateway CORS wiring. The initial Lambda is an inline placeholder, replaced in a subsequent commit by the backend Dockerfile.lambda container.
ConversionStack uses DockerImageFunction for the LibreOffice Lambda and wires S3 event notifications for .docx and .doc uploads to the documents/ prefix. The bucket is imported by ARN rather than passed as a construct to avoid a cross-stack notification dependency cycle.
A notable 08884d4 sets RemovalPolicy.DESTROY with autoDeleteObjects: true on all buckets for clean POC teardown. This is a deliberate POC choice; it needs to be reversed before production use.
The Lambda Token authorizer is a pre-Cognito stub. It is replaced by a native Cognito User Pool authorizer in a later commit not covered in this topic.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?