Building and Testing a Serverless Weather REST API with AWS CDK, Jest, GitHub and AWS CodePipeline

Jose De kajos — Thu, 12 Nov 2026 11:23:02 +0000

A practical, step-by-step guide from project setup to AWS deployment, including the errors I hit along the way and how I fixed them.
Repository: https://github.com/Josedekajos/weather-api-cicd Stack: TypeScript · JavaScript · Node.js · AWS CDK · Lambda · API Gateway · DynamoDB · CodePipeline · GitHub · Jest

Introduction
As part of my cloud computing and DevOps learning journey, I completed the Educloud Academy course Unit Testing and CI/CD Deployment with Jest, GitHub and AWS CodePipeline.
The goal was to learn how to define cloud infrastructure with the AWS Cloud Development Kit (CDK), organize it into deployment stages, configure a CI/CD pipeline, write automated tests with Jest, and test an API running on AWS.
I didn't want to stop at code that only runs on my laptop. I defined the AWS resources, synthesized them into CloudFormation templates, validated them with automated tests, deployed the Development environment, and sent a real HTTP request to the live API.
This article documents the whole process: project structure, key code, commands, errors, fixes and final results. My aim is that you can reproduce it on your own machine.

What We're Building
A serverless Weather REST API built on three AWS services:
• Amazon API Gateway exposes an HTTP endpoint.
• AWS Lambda processes the requests.
• Amazon DynamoDB provides a table for weather records.
AWS CDK defines all of these in TypeScript instead of clicking through the AWS Console. Jest tests the infrastructure definitions and the Lambda handler. AWS CodePipeline uses the GitHub repository as its source and organizes deployments into Development and Production stages.
Architecture
Developer
|
v
GitHub Repository
|
v
AWS CodePipeline
|
Build/Synth
|
+-------+-------+
| |
v v
Development Production
| |
v v
API Gateway API Gateway
| |
v v
Lambda Lambda
| |
v v
DynamoDB DynamoDB
Two honest caveats up front

One Lambda, not five. The course handout describes five Lambda functions for the CRUDL operations. In my implementation I built and deployed a single function, createWeather. The other four were not implemented.
No persistence yet. The Lambda has permission to write to DynamoDB, but the handler currently just returns the submitted data instead of saving it. The live API test therefore verifies the API Gateway → Lambda integration, not database persistence. I'd rather tell you this now than have you discover it halfway through. ________________________________________ Prerequisites and Environment You'll need: Software Purpose Node.js JavaScript runtime npm Package management Git Version control AWS CLI AWS account access AWS CDK Infrastructure deployment TypeScript Application and infrastructure code Visual Studio Code Code editor Versions I used (Windows 11, PowerShell): Tool Version Node.js 22.18.0 npm 10.9.3 AWS CLI 2.36.27 AWS CDK CLI (project-local) 2.1146.1 Python 3.13.7 Git 2.56.0 Verify your installations: node --version npm --version git --version aws --version cdk --version ________________________________________ Part 1: Getting Started Create the GitHub repository I created a repository called weather-api-cicd, then cloned it: git clone https://github.com/Josedekajos/weather-api-cicd.git cd weather-api-cicd Initialize the CDK project cdk init app --language typescript This generates the starting structure: weather-api-cicd/ ├── bin/ │ └── weather-api-cicd.ts ├── lib/ │ └── weather-api-cicd-stack.ts ├── test/ │ └── weather-api-cicd.test.ts ├── cdk.json ├── jest.config.js ├── package.json ├── package-lock.json ├── tsconfig.json └── README.md • bin/ is the entry point of the CDK app. • lib/ holds the infrastructure stack and pipeline definitions. • test/ holds the automated tests. • src/ (which we add later) holds the JavaScript Lambda handler. The CDK commands you'll use constantly # List available CDK stacks npx cdk list

Build the TypeScript project

npm run build

Generate CloudFormation templates

npx cdk synth

Compare local infrastructure with deployed infrastructure

npx cdk diff

Deploy a stack

npx cdk deploy
cdk synth is especially useful: it converts your infrastructure code into CloudFormation templates before anything is deployed.
Configure AWS credentials
I used a named AWS CLI profile called internship in the us-east-1 region. Verify yours works:
aws sts get-caller-identity --profile internship --region us-east-1
A named profile keeps this project separate from any other AWS configuration you have.
Never publish your AWS access keys, secret keys or GitHub personal access token in a repository or an article.
Store the GitHub token in AWS Secrets Manager
CodePipeline needs access to your repository.

Generate a GitHub personal access token.
Open the AWS Management Console and search for Secrets Manager.
Choose Store a new secret → Other type of secret → plain text.
Paste the token.
Name the secret exactly github-token.
Review and save. CDK then references the secret without hardcoding it: SecretValue.secretsManager('github-token') Configure AWS CodePipeline import { CodePipeline, ShellStep, CodePipelineSource, } from 'aws-cdk-lib/pipelines';

const pipeline = new CodePipeline(this, 'Pipeline', {
synth: new ShellStep('synth', {
input: CodePipelineSource.gitHub(
'Josedekajos/weather-api-cicd',
'main',
{
authentication: SecretValue.secretsManager('github-token'),
}
),
commands: [
'npm ci',
'npm run build',
'npx cdk synth',
],
}),
});
The synth step runs three commands: npm ci installs dependencies from the lockfile, npm run build compiles the TypeScript, and npx cdk synth generates the CloudFormation templates. That's the foundation of the automated workflow.

Part 2: Adding Deployment Stages
Rather than defining every resource directly in the pipeline stack, I created a reusable stage class.
lib/pipeline-stage.ts
import { Stage, StageProps } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import { LambdaStack } from './lambda-stack';

export class PipelineStage extends Stage {
constructor(
scope: Construct,
id: string,
props: StageProps
) {
super(scope, id, props);

// Instantiate the Lambda stack
new LambdaStack(this, 'lambdaStack', {
  stageName: props.stageName ?? id.toLowerCase(),
});

}
}
PipelineStage extends CDK's Stage, creates a LambdaStack, and passes it a stage name. That lets one infrastructure definition serve several environments.
Add the Development and Production stages
Inside the main pipeline stack:
pipeline.addStage(
new PipelineStage(this, 'PipelineDevStage', {
stageName: 'dev',
})
);

pipeline.addStage(
new PipelineStage(this, 'PipelineProdStage', {
stageName: 'prod',
})
);
Both environments share the same definition, but resource names include the stage name:
devweatherApiTable
prodweatherApiTable
Less duplication, easier maintenance.
Verify the stages
npx cdk list --profile internship
My output:
WeatherApiCicdStack

WeatherApiCicdStack/PipelineDevStage/lambdaStack (dev-lambdaStack)

WeatherApiCicdStack/PipelineProdStage/lambdaStack (prod-lambdaStack)
Both stages are recognized.

Part 3: Building the Stack
This is where the real infrastructure lives. I created lib/lambda-stack.ts containing:
• a DynamoDB table
• an API Gateway REST API
• a Lambda function
• permission for the Lambda to write to DynamoDB
• a POST endpoint wired to the Lambda
Imports and props
import { StackProps } from 'aws-cdk-lib';
import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';

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

export interface LambdaStackProps extends StackProps {
stageName: string;
}
The DynamoDB table
const table: dynamodb.Table = new dynamodb.Table(
this,
${props.stageName}WeatherApiTable,
{
tableName: ${props.stageName}weatherApiTable,
partitionKey: {
name: 'id',
type: dynamodb.AttributeType.STRING,
},
removalPolicy: cdk.RemovalPolicy.DESTROY,
}
);
• tableName is stage-specific.
• partitionKey is id, a string.
• removalPolicy: DESTROY deletes the table when the stack is destroyed.
Production warning: RemovalPolicy.DESTROY is fine for a temporary learning environment. A real production database should use a retention policy and backups.
The API Gateway REST API
const weatherApi: apigw.RestApi = new apigw.RestApi(
this,
'weather_rest_api',
{
restApiName: ${props.stageName} Weather Rest Api,
description: 'This service saves weather data.',
}
);
This produces APIs named dev Weather Rest Api and prod Weather Rest Api.
The Lambda function
const createWeatherLambda: lambda.Function = new lambda.Function(
this,
'CreateWeatherLambdaFunction',
{
functionName: ${props.stageName}-cdk-typescript-create,
runtime: lambda.Runtime.NODEJS_22_X,
handler: 'createWeather.lambdaHandler',
code: lambda.Code.fromAsset('src'),
environment: {
TABLE_NAME: table.tableName,
STAGE_NAME: props.stageName,
},
}
);
• runtime is Node.js 22.
• handler points to the exported lambdaHandler in createWeather.js.
• code loads from the src directory.
• TABLE_NAME and STAGE_NAME are passed as environment variables.
Function names come out as dev-cdk-typescript-create and prod-cdk-typescript-create.
Permissions and the endpoint
table.grantWriteData(createWeatherLambda);

weatherApi.root
.addResource('create-weather')
.addMethod(
'POST',
new apigw.LambdaIntegration(createWeatherLambda)
);
grantWriteData gives the function's IAM role write access to the table. Note that this doesn't make the handler write anything. The application code has to do that too.
The second block creates POST /create-weather, which invokes the Lambda.
The complete lib/lambda-stack.ts
import { StackProps } from 'aws-cdk-lib';
import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';

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

export interface LambdaStackProps extends StackProps {
stageName: string;
}

export class LambdaStack extends cdk.Stack {
constructor(
scope: Construct,
id: string,
props: LambdaStackProps
) {
super(scope, id, props);

// Create the DynamoDB table
const table: dynamodb.Table = new dynamodb.Table(
  this,
  `${props.stageName}WeatherApiTable`,
  {
    tableName: `${props.stageName}weatherApiTable`,
    partitionKey: {
      name: 'id',
      type: dynamodb.AttributeType.STRING,
    },
    removalPolicy: cdk.RemovalPolicy.DESTROY,
  }
);

// Create the API Gateway REST API
const weatherApi: apigw.RestApi = new apigw.RestApi(
  this,
  'weather_rest_api',
  {
    restApiName: `${props.stageName} Weather Rest Api`,
    description: 'This service saves weather data.',
  }
);

// Define the Lambda function
const createWeatherLambda: lambda.Function =
  new lambda.Function(
    this,
    'CreateWeatherLambdaFunction',
    {
      functionName: `${props.stageName}-cdk-typescript-create`,
      runtime: lambda.Runtime.NODEJS_22_X,
      handler: 'createWeather.lambdaHandler',
      code: lambda.Code.fromAsset('src'),
      environment: {
        TABLE_NAME: table.tableName,
        STAGE_NAME: props.stageName,
      },
    }
  );

// Grant Lambda permission to write to DynamoDB
table.grantWriteData(createWeatherLambda);

// Create the POST /create-weather endpoint
weatherApi.root
  .addResource('create-weather')
  .addMethod(
    'POST',
    new apigw.LambdaIntegration(createWeatherLambda)
  );

}
}
The Lambda handler: src/createWeather.js
exports.lambdaHandler = async (event) => {
try {
const weatherData = JSON.parse(event.body || '{}');

return {
  statusCode: 200,
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    message: 'Weather data received successfully',
    data: weatherData
  })
};

} catch (error) {
return {
statusCode: 400,
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({
message: 'Invalid request body'
})
};
}
};
A valid request returns 200 with a success message and the submitted data. Invalid JSON returns 400 with an error message. That was enough for the course's live integration test, though it doesn't persist anything to DynamoDB yet.
Build and synthesize
npm run build
npx cdk synth
The build checks the TypeScript; synthesis generates the CloudFormation templates. I also inspected the synthesized templates to confirm the Development and Production stacks contained their expected DynamoDB tables.

Part 4: Writing the Tests
The point of testing here is to verify that the CDK stack contains what you expect before you deploy it. I created two test files:
test/
├── weather-api-cicd.test.ts (infrastructure tests)
└── lambda.test.ts (handler test)
Infrastructure tests
import * as cdk from 'aws-cdk-lib';

import {
Template,
Capture,
} from 'aws-cdk-lib/assertions';

import { LambdaStack } from '../lib/lambda-stack';

test('DynamoDB Table Created', () => {
const app = new cdk.App();

const stack = new LambdaStack(app, 'MyTestStack', {
stageName: 'Dev',
});

const template = Template.fromStack(stack);

template.hasResource('AWS::DynamoDB::Table', {
Properties: {
TableName: 'DevweatherApiTable',
},
});
});

test('ApiGateway RestApi Created', () => {
const app = new cdk.App();

const stack = new LambdaStack(app, 'MyTestStack', {
stageName: 'Dev',
});

const template = Template.fromStack(stack);

template.hasResource('AWS::ApiGateway::RestApi', {
Properties: {
Name: 'Dev Weather Rest Api',
},
});
});

test('Verify Number of Lambda Functions', () => {
const app = new cdk.App();

const stack = new LambdaStack(app, 'MyTestStack', {
stageName: 'Dev',
});

const template = Template.fromStack(stack);

template.resourceCountIs('AWS::Lambda::Function', 1);
});

test('Create Lambda Function typescript Exist', () => {
const app = new cdk.App();

const stack = new LambdaStack(app, 'MyTestStack', {
stageName: 'Dev',
});

const template = Template.fromStack(stack);

const envCapture = new Capture();

template.hasResourceProperties('AWS::Lambda::Function', {
FunctionName: 'Dev-cdk-typescript-create',
});

template.hasResourceProperties('AWS::Lambda::Function', {
Environment: envCapture,
});

expect(envCapture.asObject()).toEqual({
Variables: {
TABLE_NAME: {
Ref: expect.stringMatching(/^DevWeatherApiTable/),
},
STAGE_NAME: 'Dev',
},
});
});
What each one checks:

DynamoDB table: it exists with the correct stage-specific name.
API Gateway: the REST API exists with the expected name.
Lambda count: exactly one function. The workshop expected five, but my stack has one, so I adjusted the test to match reality. A test should verify your actual implementation.
Lambda properties: the function name is correct, TABLE_NAME references the table, and STAGE_NAME is Dev. Capture lets us inspect generated CloudFormation properties without hardcoding the full generated logical ID. Handler test import { lambdaHandler as createWeather } from '../src/createWeather';

test('create weather', async () => {
const result = await createWeather({
body: JSON.stringify({
weather: 'hot',
town: 'Douala',
}),
});

expect(result).toMatchObject({
body: expect.any(String),
statusCode: expect.any(Number),
});
});
This is a deliberately basic test: it confirms the handler returns a string body and a numeric status code. It doesn't verify DynamoDB writes or assert the exact response message. Together with the four infrastructure tests, that's five tests across two suites.

Errors I Hit (and How I Fixed Them)
Troubleshooting was the most educational part of the project.
Error 1: CDK CLI and library version mismatch
My globally installed CLI (2.1138.0) was older than the schema version the installed CDK library required.
Fix: use the project-local CLI via npx:
npx cdk --version

2.1146.1

Lesson: keep the CLI and library versions compatible, and prefer npx cdk so the project uses its own installed version.
Error 2: CodeBuild concurrent build quota was zero
When I checked AWS CodeBuild, the concurrent build quota for the Linux/Small environment was BUILD_GENERAL1_SMALL = 0, meaning CodeBuild couldn't start a build in that environment. I checked it with:
aws service-quotas list-service-quotas --service-code codebuild
--profile internship --region us-east-1
--query "Quotas[?contains(QuotaName, 'Concurrent')].[QuotaName,Value,QuotaCode,Adjustable]" `
--output table
The relevant quota code was L-9D07B6EF. I had already requested an increase to one concurrent build, and the request history showed:
Requested limit: 1
Status: CASE_OPENED
It had been received but not approved, and I didn't submit a duplicate.
Workaround: I deployed the Development stack directly from my machine with CDK, which let me complete the live API test without CodeBuild.
This distinction matters: deploying manually with CDK is not the same as having a fully working automated CodePipeline.
Error 3: TypeScript couldn't find declarations for the JavaScript handler
test/lambda.test.ts:2:48 - error TS7016:

Could not find a declaration file for module
'../src/createWeather'.

'C:/Users/josed/weather-api-cicd/src/createWeather.js'
implicitly has an 'any' type.
My test was TypeScript, but the handler was JavaScript, so TypeScript had no type information for it.
Fix: add src/createWeather.d.ts:
export declare const lambdaHandler: (
event: {
body?: string | null;
}
) => Promise<{
statusCode: number;
headers?: Record;
body: string;
}>;
This only describes the handler to TypeScript; it doesn't change the JavaScript implementation. After saving it, the build and tests ran cleanly.
Error 4: "Jest worker failed to exit gracefully"
A worker process has failed to exit gracefully
and has been force exited.

This is likely caused by tests leaking due to improper teardown.
All tests still passed. This is a worker-cleanup warning, not a failed assertion. If it persists, a useful diagnostic is:
npm test -- --detectOpenHandles
I didn't treat it as a blocker since all five tests passed.
Error 5: CDK couldn't find the stack by its short name
npx cdk deploy dev-lambdaStack --profile internship
No stacks match the name(s) dev-lambdaStack
The stack is nested inside a CDK stage. cdk list shows the real path, so I used that:
npx cdk deploy "WeatherApiCicdStack/PipelineDevStage/lambdaStack" --profile internship
Lesson: for nested stacks, use the full path shown by cdk list.
Error 6: npm vulnerability warnings
20 vulnerabilities
3 low
17 moderate
Installation completed and tests passed. I deliberately did not run npm audit fix --force, since force-upgrading without review can introduce breaking changes. For a production project, inspect the audit report and update dependencies carefully.

Part 5: Running the Tests
Install dependencies and run the suite:
npm install
npm test
Result:
PASS test/lambda.test.ts

PASS test/weather-api-cicd.test.ts

Test Suites: 2 passed, 2 total

Tests: 5 passed, 5 total

Snapshots: 0 total
All five tests passed. Then:
npm run build
npx cdk synth
Both succeeded once the TypeScript declaration issue was fixed.

Deploying the Development Stack
With the build, synth and tests green, I listed the stacks and deployed Development:
npx cdk list --profile internship
npx cdk deploy "WeatherApiCicdStack/PipelineDevStage/lambdaStack" --profile internship
CDK listed the resources it was creating, and the deployment completed:
CREATE_COMPLETE
AWS::Lambda::Permission

CREATE_COMPLETE
AWS::CloudFormation::Stack

dev-lambdaStack

Deployment time: 68.14s
Total time: 125.01s
AWS generated an API endpoint in this form:
https://.execute-api.us-east-1.amazonaws.com/prod/
So the Create Weather endpoint is:
POST https://.execute-api.us-east-1.amazonaws.com/prod/create-weather
Notice the /prod/ in the URL. That's the API Gateway stage name; it does not mean my separate Production CDK environment was deployed.

Testing the Live API
With Development deployed, I sent a real HTTP POST from PowerShell.
$body = @{
weather = "hot"
town = "Douala"
} | ConvertTo-Json

Invoke-RestMethod -Method Post
-Uri "https://.execute-api.us-east-1.amazonaws.com/prod/create-weather" -ContentType "application/json"
-Body $body
The API responded:
message data

Weather data received successfully
@{weather=hot; town=Douala}
That confirmed that:

The API Gateway endpoint was reachable.
The POST method was configured correctly.
API Gateway invoked the Lambda function.
The handler parsed the submitted JSON.
The Lambda returned a successful response containing the submitted data. This wasn't just a local unit test. It was a real request to an API running in AWS. ________________________________________ Final Project Structure weather-api-cicd/ ├── bin/ │ └── weather-api-cicd.ts ├── lib/ │ ├── weather-api-cicd-stack.ts │ ├── pipeline-stage.ts │ └── lambda-stack.ts ├── src/ │ ├── createWeather.js │ └── createWeather.d.ts ├── test/ │ ├── weather-api-cicd.test.ts │ └── lambda.test.ts ├── cdk.json ├── jest.config.js ├── package.json ├── package-lock.json ├── tsconfig.json ├── README.md └── .gitignore The generated configuration files are best taken from the repository; the code above covers the infrastructure, handler, declaration and test files I implemented and verified. ________________________________________ Reproduce It Yourself
Clone the repo git clone https://github.com/Josedekajos/weather-api-cicd.git cd weather-api-cicd
Install dependencies: npm install
Configure AWS credentials and verify them: aws sts get-caller-identity --profile internship Use the us-east-1 region for this walkthrough.
Create the github-token secret in AWS Secrets Manager. Never commit the token.
Build: npm run build
Test: npm test (expect 2 suites and 5 tests passing)
Synthesize: npx cdk synth
List stacks: npx cdk list --profile internship
Deploy Development: npx cdk deploy "WeatherApiCicdStack/PipelineDevStage/lambdaStack" --profile internship
Test the API with the URL from your own deployment: $body = @{ weather = "hot" town = "Douala" } | ConvertTo-Json

Invoke-RestMethod -Method Post
-Uri "create-weather" -ContentType "application/json"
-Body $body
Keep in mind that credentials, permissions, service quotas and regions differ between accounts. Success on one account doesn't guarantee the same quotas on another.

What Was Completed and What Remains
Project component Result
TypeScript CDK project setup Completed
GitHub repository setup Completed
AWS profile configuration Verified
GitHub token in Secrets Manager Configured
CodePipeline configuration Implemented
Development and Production stage definitions Implemented
DynamoDB infrastructure definition Completed
API Gateway infrastructure definition Completed
Create Weather Lambda definition Completed
Jest infrastructure tests Passed
Lambda handler test Passed
TypeScript build Passed
CDK synthesis Passed
Development AWS deployment Successful
Live API POST request Successful
Production stack deployment Not yet confirmed
Automated CodePipeline execution Not yet confirmed (CodeBuild quota request pending)
The pipeline and its stages are configured in the project, but I did not establish a successful end-to-end automated pipeline run during this workshop. The CodeBuild quota increase was still open, which is why I deployed Development locally.
Next steps
• Implement the handler's DynamoDB write so data is actually persisted.
• Build the remaining four CRUDL Lambda functions.
• Complete a full automated CodePipeline run once the quota is approved.
• Deploy and verify the Production stage.
• Replace RemovalPolicy.DESTROY with a retention policy for production data.

What I Learned
• Infrastructure as Code: defining AWS resources in TypeScript with CDK instead of the console.
• Serverless architecture: exposing a REST API with Lambda and API Gateway.
• Database infrastructure: defining a DynamoDB table and granting Lambda write access.
• Environment separation: using CDK stages to organize Development and Production from one definition.
• Automated testing: using Jest and CDK assertions to verify resources before deployment.
• CI/CD concepts: a GitHub-based CodePipeline with a synth step and separate deployment stages.
• Troubleshooting: CLI version compatibility, TypeScript declarations, Jest warnings, AWS quotas and nested stack names.
Most importantly, I went from writing infrastructure code locally to deploying a Development stack and getting a successful response from an API hosted on AWS.

Conclusion
This Educloud Academy workshop was a valuable practical step in my AWS, DevOps and software engineering journey. It brought TypeScript, AWS CDK, Jest, GitHub, Lambda, API Gateway, DynamoDB and CodePipeline together in one project.
The most satisfying moment was seeing the deployed API answer a real HTTP request. The project also reminded me that cloud deployment is rarely a straight line: version compatibility, permissions, quotas and configuration errors are part of real cloud engineering, and learning to diagnose them matters as much as writing the initial code.
I look forward to building on this foundation with more advanced cloud and serverless applications.

Tags: AWS CDK · TypeScript · Node.js · Jest · GitHub · AWS CodePipeline · AWS CodeBuild · AWS Lambda · Amazon API Gateway · Amazon DynamoDB · AWS Secrets Manager · CloudFormation
Project repository: https://github.com/Josedekajos/weather-api-cicd Course: Educloud Academy, Unit Testing and CI/CD Deployment with Jest, GitHub and AWS CodePipeline

DEV Community: Jose De kajos

Building and Testing a Serverless Weather REST API with AWS CDK, Jest, GitHub and AWS CodePipeline

Build the TypeScript project

Generate CloudFormation templates

Compare local infrastructure with deployed infrastructure

Deploy a stack

2.1146.1