AWS CDK Set Parameter Store Value

Problem:

There are multiple ways to set a parameter store value. Which one should I use?

Solution:

1. Set parameter at deploy time:

Use this pattern when you want to create or update a plain-text SSM parameter during deployment. Creates an AWS::SSM::Parameter resource that resolves at deploy time.

new ssm.StringParameter(this, 'Param', {
  parameterName: '/my/plain/parameter',
  stringValue: 'my-value',
});

2.   Set parameter with a JSON value:

Use when you need to store structured data (e.g., configuration or mapping) as a JSON string.
The object is serialized with JSON.stringify() before being written to SSM.

new ssm.StringParameter(this, 'JsonParam', {
  parameterName: '/app/config',
  stringValue: JSON.stringify({
    apiUrl: 'https://api.example.com',
    featureFlags: { enableNewUI: true, betaAccess: false },
  }),
});

To read it back, retrieve the value and parse it:.

const config = JSON.parse(ssm.StringParameter
  .fromStringParameterAttributes(this, 'JsonParamRef', {
    parameterName: '/app/config',
  })
  .stringValue);

3.  Set parameter with a lazy value:

Use when the parameter value depends on another construct (e.g., a pipeline name) and must be evaluated dynamically at synth. cdk.Lazy defers the value computation until synthesis.

new ssm.StringParameter(this, 'LazyParam', {
  parameterName: '/pipeline/name',
  stringValue: cdk.Lazy.string({
    produce: () => pipeline.pipeline.pipelineName,
  }),
});

VSCode Simple Formatter Setup

Question: What is a simple VSCode formatter setup across projects that require different formatters?

Answer:

VSCode user settings are stored outside the project on local.

VSCode workspace settings are stored in .vscode\settings.json. So in a team environment do set workspace settings and commit to repo. That way the entire team has the same formatter setting.

• In  File > Preferences > Settings, Enable Format On Save. Simple best/common practice.
  
  
• In  File > Preferences > Settings, Workspace level, set Default Formatter. Different projects are likely to need different formatters. Old projects are probably using old formatters while new projects will want to use new formatters.

User Guide Mini Crane Scale KLAU Model OCS-L

I purchased this scale and it came with this booklet. However, I couldn't find this guide online so I've copied it here for easy reference.

 

AWS CDK Get Parameter Store Value

Problem:

There are multiple ways to get a parameter store value. Which one should I use?

Solution:

1. Resolve at deploy time with no extra synth:

Use this pattern when you need the parameter value to resolve at deployment time rather than during `cdk synth`. This avoids CDK context lookups, cached values, and "double synth" behavior when parameters differ per environment.

const value = ssm.StringParameter
  .fromStringParameterAttributes(this, 'Param', {
    parameterName: '/my/plain/parameter',
  }).stringValue;

Secure:
const value = cdk.SecretValue.secretsManager('/my/secure/parameter');

2. Resolve at synth time:

Use this syntax when you need a fixed, environment-specific value at synthesis time instead of at deployment. This retrieves the actual SSM parameter value during cdk synth and stores it in the cdk.context.json file. Use this approach when conditional logic in your CDK code requires the literal value (e.g., if/else branching to decide which stacks or resources to include).

const value = ssm.StringParameter.valueForStringParameter(this, 'my-parameter-name');

Secure:

const value = cdk.SecretValue.ssmParameter('my-parameter-name');

3. Synthesis-time value (lookup)

Use this when you need the actual parameter value at synthesis time (not deployment). CDK will resolve it during `cdk synth`, cache it in `cdk.context.json`, and reuse it until refreshed. Ideal for feature flags or conditional logic that must run before deployment. Avoid for frequently changing values—requires re-synth to update.

const value = ssm.StringParameter.valueFromLookup(this, 'my-parameter-name');

https://docs.aws.amazon.com/cdk/v2/guide/get_ssm_value.html

AWS CDK Set CloudFormation Property Escape Hatch

 Problem:

The CDK does not always support all CloudFormation properties. A super simple escape hatch is to use  a addOverride one-liner. There are more robust escape hatches but this is super simple especially for deeply nested properties. Ideally, these are temporary until the CDK exposes properties directly.

Solution:

// The CDK does not currently support dynamic wildcard branch names (and other GitHub version 2 properties) but CloudFormation does.
const cfnPipeline = pipeline.node.defaultChild as codepipeline.CfnPipeline;
cfnPipeline.addOverride('Properties.Stages.0.Actions.0.Configuration.BranchName', `*-${env}-*`);

AWS CDK Chart.js Canvas Layer for AWS Lambda

 Problem:

Using the AWS CDK v2, how to deploy the "Canvas Layer for AWS Lambda" serverless application and attach the layer to a Lambda function.

lambda-layer-canvas-nodejs

https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:990551184979:applications~lambda-layer-canvas-nodejs

https://charoitel.github.io/lambda-layer-canvas-nodejs/

To get the latest semanticVersion:

1. Open the AWS Management Console.
2. Navigate to the Serverless Application Repository.
3. Search for lambda-layer-canvas-nodejs.
4. View the application details to find the latest version.

Solution:

import { Stack } from 'aws-cdk-lib';

import { Construct } from 'constructs';

import { CfnApplication } from 'aws-cdk-lib/aws-sam';

import * as lambda from 'aws-cdk-lib/aws-lambda';

import * as lambdaNJS from 'aws-cdk-lib/aws-lambda-nodejs';

export default class ChartStack extends Stack {

    constructor(scope: Construct, id: string, props: cdk.StackProps) {

        super(scope, id, props);

        const chartJsApp = new CfnApplication(this, 'ChartJsApp', {

            location: {

                applicationId: 'arn:aws:serverlessrepo:us-east-1:990551184979:applications/lambda-layer-canvas-nodejs',

                semanticVersion: '2.11.3'

            }

        });

        const layerArn = chartJsApp.getAtt('Outputs.LayerVersion').toString();

        const njs = new lambdaNJS.NodejsFunction(this, 'ChartLambda', {

            entry: 'main.ts',

            handler: 'handler',

            runtime: lambda.Runtime.NODEJS_18_X,

            layers: [lambda.LayerVersion.fromLayerVersionArn(this, 'ChartJsLayer', layerArn)]

        });

        // Add dependency to ensure the layer is deployed before the function

        njs.node.addDependency(chartJsApp);

    }

}

AWS CDK V2 Synth Error when Bundling a NodejsFunction

 Problem:
AWS CDK version 2 synth error when bundling a NodejsFunction with somewhat complicated Typescript source code.

Error:
RangeError: Maximum call stack size exceeded

Solution:
Upgrade to a more recent version of npm package "esbuild". In this case, upgrading to version 0.19.12 resolve the issue even though this isn't the most recent version available. Other third party npm package constraints did not allow the latest version to be installed. npm i -D esbuild@0.19.12