Skip to main content

Resource Bundles

Resource bundles allow you to add specific AWS services to existing projects. Think of them as modular components that you can mix and match based on your needs.

What are Resource Bundles?​

Resource bundles are individual AWS service generators that can be added to existing services or used to build custom architectures.

Available Resource Bundles​

  • API Service - Lambda + API Gateway for REST endpoints
  • DynamoDB - NoSQL database tables with indexes
  • SNS/SQS - Messaging services for event-driven architectures
  • S3 - Object storage buckets with policies

When to Use Resource Bundles​

  • Adding functionality to existing services
  • Building custom architectures
  • Incremental development approach
  • Service-specific requirements

Usage Examples​

Add API (API Gateway + Lambda)​

nx g @mhshahzad/nx-cdk-deploy:api-service --project=orders --name=orders-api
  • Creates an API entrypoint and Lambda handler(s)
  • Wires permissions and outputs
  • See: API Service

Add DynamoDB​

nx g @mhshahzad/nx-cdk-deploy:dynamodb --project=orders \
  --tableName=OrdersTable \
  --partitionKey=id:string \
  --sortKey=createdAt:number
  • Generates a table and recommended defaults
  • Optionally adds GSIs/LSIs depending on flags
  • See: DynamoDB

Add Messaging (SNS + SQS)​

nx g @mhshahzad/nx-cdk-deploy:sns-sqs --project=orders \
  --topicName=order-events \
  --queueName=order-jobs
  • Creates a topic, subscription, and queue(s)
  • Useful for event-driven and async workflows
  • See: SNS/SQS

Add S3 Bucket​

nx g @mhshahzad/nx-cdk-deploy:s3 --project=orders --bucketName=orders-artifacts
  • Creates an S3 bucket with sensible defaults and policies
  • See: S3

Redeploy the service​

nx deploy orders --configuration=dev

Composition Strategy​

  • Incremental: start with a preset, then add bundles as needs evolve.
  • Composable: combine multiple bundles (API + DynamoDB + SNS/SQS + S3).
  • Environment-aware: configure per-env settings (throughput, retention, bucket policies) via project config and env variables.

Best Practices​

  • Idempotency: re-running generators should be safe; review diffs in Git.
  • Naming: prefer deterministic names (e.g., orders-<env>-events) to simplify ops.
  • Permissions: keep least-privilege IAM policies; grant only what the Lambda needs.
  • Tagging: apply tags for cost allocation and governance.
  • Testing: use CDK assertions and/or integration tests for critical paths.