Forem: Marko - ServerlessLife.com

CDK Booster - Speeding Up Bundling of Lambda Handlers

Marko - ServerlessLife.com — Mon, 29 Sep 2025 15:57:21 +0000

Stop waiting for CDK to bundle Lambda functions. CDK Booster accelerates TypeScript/JavaScript builds with seamless integration.

One of AWS Cloud Development Kit (AWS CDK)'s main drawbacks is that it executes tasks sequentially, including the bundling of Lambda code. For large projects with many functions, this can make the process painfully slow.

That’s why I created CDK Booster. It bundles all Lambda functions created with the NodejsFunction construct in one go, producing the same per-function assets CDK would normally generate. It’s a drop-in replacement: no code changes required, just installation and a small tweak to cdk.json.

CDK Booster aslo prevents double bundling. Sometimes CDK triggers synthesis twice because certain resources require lookups before they can be resolved. Normally, this would mean all Lambda functions are bundled twice as well. CDK Booster detects this and prevents unnecessary duplicate bundling.

Key Benefits

Much faster builds on projects with many TypeScript/JavaScript Lambda functions
Seamless integration – drop-in replacement, no code changes needed
Smarter bundling – avoids running twice during repeated synth

Setup

npm install cdk-booster

Modify your cdk.json file:

Replace this:

{
  "app": "npx ts-node --prefer-ts-exts bin/your_app.ts",
  ...
}

With this:

{
  "app": "npx cdk-booster bin/your_app.ts",
  ...
}

bin/your_app.ts is location to your CDK app.

All functions created with the NodejsFunction construct are automatically bundled using CDK Booster:

import * as lambda_nodejs from "aws-cdk-lib/aws-lambda-nodejs";

const functionTestJsEsModule = new lambda_nodejs.NodejsFunction(
  this,
  "TestJsEsModule",
  {
    entry: "lambda.ts",
  }
);

How It Works

CDK Booster operates through a multi-phase process:

Transpilation – ESbuild compiles CDK code and injects discovery logic for Lambda functions.
Descovery phase – CDK code runs in Node.js worker threads, identifying functions and build commands.
Bundling – all handlers are bundled at once using ESbuild’s multiple entry points. This approach is what provides the significant speed improvement. Bundled assets are placed in the cdk.out/bundling-temp-* folders for CDK to consume.
CDK synth – the regular CDK process runs, skipping redundant bundling since assets are ready.
Asset reuse – if synth reruns (e.g., for lookups), CDK Booster reuses existing bundles.

Summary

CDK Booster shines in large projects with dozens of Lambda functions, where sequential bundling can significantly slow down the build process. For smaller applications, the speedup is less dramatic but still helpful.

Note that bundling itself is rarely the slowest step in deployment—most of the time is consumed by CloudFormation. CDK Booster targets the bundling phase specifically, making it faster and avoiding duplicate work when synthesis runs more than once.

The result is a leaner, more efficient development workflow: less waiting, quicker feedback, and more time to focus on building features instead of watching your code bundle.

Lambda Live Debugger vs Official AWS Remote Debugging

Marko - ServerlessLife.com — Tue, 22 Jul 2025 16:37:11 +0000

AWS now supports Lambda remote debugging. How does it compare to Lambda Live Debugger, and why is that great news for the project.

AWS finally supports Lambda remote debugging — something developers have been waiting for for years. This is similar to my Lambda Live Debugger. This is great news for developers and also for the Lambda Live Debugger project. It will help make this approach more popular, as more developers will see that this is by far the most productive way of developing serverless applications. And since Lambda Live Debugger has several key advantages, this also means great news for the project.

Here is a comparison between the two solutions:

Architecture

Both solutions work by attaching a Layer to the Lambda function. The official AWS solution removes the Layer immediately after the Lambda is invoked. Lambda Live Debugger leaves the Layer attached until you decide to remove it. Both solutions use AWS IoT to communicate with your computer.

The official AWS solution runs a debugger on the Lambda itself and then connects to your VS Code. That means with the official AWS debugger, when you change code, you must upload it to the cloud to debug.

In contrast, Lambda Live Debugger sends the event alongside IAM permissions to your computer, and the debugger runs locally. Since the code runs on your machine, you don’t need to upload anything. Reloading and, if needed, transpiling/compiling TypeScript to JavaScript happens automatically and instantly.

However, there’s one important benefit to how the official AWS debugger works: since the debugger is running in Lambda, it has access to resources inside a VPC, which Lambda Live Debugger cannot access.

Supported Languages

Official AWS Lambda remote debugging supports JavaScript, Python, and Java. JavaScript source maps are not supported, which makes debugging TypeScript impossible. If I understood correctly, support is on the way. Because source maps are not supported, it would be extremely difficult/impossible to debug code that was bundled and minified.

Lambda Live Debugger only supports JavaScript and TypeScript. TypeScript support with automatic transpiling/compiling is a key feature.

Lambda Handler Source Code

Official AWS Lambda debugging requires you to point to your local code or download it from the cloud. The debugger just steps through that code; actual execution still happens in the cloud. You can’t point to your TypeScript code — only to the transpiled version. That’s very hard to do if you’re using AWS CDK, because the assets are in random folders under cdk.out.

Lambda Live Debugger does not require this. It can read your framework configuration and automatically find the source code.

Supported Frameworks

The official AWS Lambda debugging does not support any framework. Linking a Lambda to the source code requires manual clicking. That’s why the solution is deeply integrated into VS Code.

Lambda Live Debugger supports all popular frameworks (CDK, Serverless Framework, SAM, Terraform, OpenTofu). This was most challenging for me when building the tool. It was especially difficult to support CDK. The tool automatically finds the Lambda's source code. You just need to enter a few key parameters when configuring the project.

Lambda Live Debugger also works if you have your own unique setup — just list your Lambdas.

Supported IDE

The official AWS debugger is integrated with VS Code via the AWS Toolkit extension. No other IDEs are supported.

Lambda Live Debugger doesn’t depend on a specific IDE — because the debugger runs on your local machine, any tool that supports JavaScript debugging works. But the tool generates debugging configuration for VS Code and JetBrains IDEs like WebStorm, so the debugging is seamless, with just starting the debugger.

Capturing Events

Official AWS Lambda remote debugging intercepts only events invoked from VS Code. That makes it impossible to intercept live events that occur in the system. You need to prepare your own sample payload. You can debug only one Lambda at a time. This makes it impossible to debug a system as a whole. I do not know why they decided to do that.

Lambda Live Debugger can debug multiple Lambdas and can capture real events that happen in the system.

Developer experience

I must say the developer experience with the official AWS solution feels clumsy. First, you need to find your Lambda in the list of all Lambdas you have in your account in your region. Then you need to link it to the source code. You need to write a sample payload, and then you can invoke the function. You need to do that for every function. If you change your code, you need to upload the new version. The VS Code extension asks you to do that for you. But the process is slow, and you always have to disconnect and reconnect the debugger to get the new version.

With Lambda Live Debugger, you just run the wizard once, where you mostly confirm the default settings. Then you start the debugger. No need to enter a sample payload, no need to reupload the code.

Summary of Benefits

Official AWS Remote Debugging:

Can access private VPC resources.
Supports Python and Java in addition to JavaScript.

Lambda Live Debugger:

Support TypeScript with automatic transpiling/compiling.
No uploads are needed when code changes.
Debug multiple Lambdas at once.
Captures real events happening in your system, not just sample events you write yourself.
Supports all popular frameworks (CDK, Serverless Framework, SAM, Terraform, OpenTofu)
Automatic configuration for VS Code and JetBrains IDEs. Works with any IDE that supports JavaScript debugging.
Automatically finds Lambda source code.
Fast, seamless developer experience integrated with your framework of choice.

Final Thoughts

It’s exciting to see AWS embrace remote debugging — it validates how powerful this approach is for serverless development. However, while the official solution lays important groundwork, it currently comes with significant limitations, especially for TypeScript developers and real-world debugging scenarios.

Lambda Live Debugger remains the most flexible, developer-friendly, and efficient option for debugging JavaScript and TypeScript Lambdas. It’s ideal for working with modern frameworks, real traffic, and complex serverless systems.

The official AWS Remote Debugging is the go-to choice if you're working with Python or Java, or if you need to access resources inside a private VPC.

As the ecosystem evolves, having both tools available is a win for developers. Choose the one that fits your workflow — or use both where they shine.

I Passed 5 AWS Certifications in 5 Days: 15 Essential Tips

Marko - ServerlessLife.com — Thu, 09 Jan 2025 07:25:18 +0000

When coffee is your best friend and determination is your fuel, passing 5 AWS certs in 5 days becomes more than a crazy goal

In January 2025, all five of my AWS certifications were set to expire: three associate-level and two professional-level certifications. For those familiar with AWS certifications, you know how challenging they can be—even for seasoned AWS professionals. While associate-level exams are tough, professional-level exams are downright brutal, far surpassing the difficulty of any university exams I’ve taken.

I decided to tackle all five exams over five days (January 2–6). Crazy? Probably. But I passed them all:

AWS Certified Solutions Architect Associate
AWS Certified Developer Associate
AWS Certified DevOps Professional
AWS Certified SysOps Administrator Associate
AWS Certified Solutions Architect Professional

This was my third time taking the associate exams and second time taking the professional ones. Here are 15 essential tips I’ve picked up along the way.

1. Pick the Best Courses

This one’s easy. Stephane Maarek’s Udemy courses are by far the best. It is unbelievable how quickly you can learn with his courses. I cannot compare it to any course I have ever gone through or any teacher I have had at school or university. It is crazy that you can get them for $10 on sale. And he constantly upgrades them. Also, buy his practice exams, you will need them. If you plan to take professional exams, buy associate courses as well. They are foundational for professional-level content.

2. Get a 50% discount

Once you pass the exam, you get a 50% discount on your next exam. It expires after 3 years. Exams are pretty expensive.

...continue reading

Add Logging to AWS Lambda Without Redeploying Using a Simple Extension

Marko - ServerlessLife.com — Tue, 19 Nov 2024 06:53:45 +0000

A reusable extension for Node.js Lambda that logs requests and responses without code changes or redeployment. Learn how to use it and how I built it.

The Challenge of Debugging AWS Lambda in Production

Debugging Lambda functions in production can be challenging. Without sufficient logging, it’s often difficult to diagnose issues in the system. You could use some observability tools like Lumigo. You could also use Lambda Live Debugger with Observability mode. In most cases, you are mostly left to the mercy of the logs you have. However, excessive logging in high-traffic serverless applications can lead to high CloudWatch costs.

The ideal solution is temporarily enabling logging without redeploying your Lambda function. But what if you didn’t build logging in a way that would support that? Is there a way to introduce this additional logging?

Fortunately, there is. Using this Lambda extension, you can add it to any Lambda function, even in production environments, with minimal impact on your system. It supports Lambda based on Nodej.js.

Debug smarter, not harder! 🔧 A Lambda extension to log requests and responses without redeployment 💪

The extension was originally developed as part of Lambda Live Debugger and a ServerlessSpy tool. Lambda Live Debugger is a tool that enables remote debugging of Lambda functions. It also speeds up development because you can avoid constant and timely redeploys. ServerlessSpy is a CDK-based library for writing elegant integration tests on AWS serverless architecture. It has an additional web console to monitor events in real-time.

...continue reading

Query DynamoDB with SQL using Athena - Leveraging EventBridge Pipes and Firehose (2/2)

Marko - ServerlessLife.com — Mon, 11 Nov 2024 12:58:05 +0000

With the help of EventBridge Pipes and Firehose, you can export DynamoDB data to S3 in near real-time, enabling you to query it using SQL via Athena.

This is the second part of a two-part series covering how to copy data from DynamoDB to S3 and query it with Athena.

Part 1: Query DynamoDB with SQL using Athena - Leveraging DynamoDB Exports to S3
Part 2 (this article): Query DynamoDB with SQL using Athena - Leveraging EventBridge Pipes and Firehose

DynamoDB is a highly scalable NoSQL database, but it has limited query capabilities like any NoSQL database. By exporting data to S3 and querying it with Athena using SQL, we can combine the scalability of DynamoDB with the flexibility of SQL queries. This offers a truly serverless approach to SQL queries.

The solution is built using CDK and TypeScript. It covers both single- and multiple-table designs.

Real-Time Data Flow to S3

In Part 1, we explored how to use DynamoDB's native export to S3. While that works well for certain use cases, it falls short when you need near-real-time data. In Part 2, we’ll demonstrate a solution to stream new DynamoDB data to S3 in near real-time using EventBridge Pipes and Firehose.

An added advantage of using Firehose over DynamoDB’s native export feature is that Firehose can convert the data to efficient formats, such as Parquet, which optimizes both storage and Athena query performance. You can also filter the data, so not all records need to be exported.

Downsides and Considerations

Delay

Exporting DynamoDB data via EventBridge Pipes and Firehose, we can achieve real-time data storage in S3, albeit with some delay. How much delay depends on which batching configuration you set on Firehose. Firehose batch the data to store multiple records into one file. This is beneficial regarding cost, and most of all, it is great for Athena because it performs better when working with larger files.

Append-Only Nature

Data in S3 is stored in an append-only format. If a record is deleted in DynamoDB, it won’t be removed from S3. Instead, you will need to store a record with a “deleted” flag and adjust your queries to account for this. Similarly, updates in DynamoDB are stored as new records, meaning that your Athena queries must be designed to retrieve the latest version of a record, which can add complexity. Those kinds of queries could be slow and expensive. But Athena is cheap, so this is not a problem if you do not have terabytes of data.

Duplicate Records

There’s no guarantee that data transferred to S3 will not duplicate records. EventBridge Pipes and Firehose do not ensure exactly-once delivery, so some records may be duplicated. Athena appears like an SQL database, but it is not. It has no constraints on the primary key, as you would subconsciously expect. And the whole process of transferring data is not idempotent, which means that it can produce duplicates. So, on most aggregate queries, you will need to use a DISTINCT SQL statement or similar approach.

While Athena is cost-effective, handling duplicate records or complex queries may lead to performance trade-offs, especially with large datasets.

...continue reading

Query DynamoDB with SQL using Athena - Leveraging DynamoDB Exports to S3 (1/2)

Marko - ServerlessLife.com — Tue, 05 Nov 2024 06:56:21 +0000

Export DynamoDB to S3 and query with Athena using SQL, unlocking powerful, scalable, and serverless data analytics

This is the first part of a two-part series covering how to copy data from DynamoDB to S3 and query it with Athena.

Part 1 (this article): Query DynamoDB with SQL using Athena - Leveraging DynamoDB Exports to S3
Part 2: Query DynamoDB with SQL using Athena - Leveraging EventBridge Pipes and Firehose

We will build two solutions using AWS CDK and TypeScript, covering both single-table and multiple-table designs.

Unlocking New Possibilities

The DynamoDB is a NoSQL database, and that fact comes with both the good and the bad. Among others, the good is that it is ultimately scalable; the bad is that it has limited query capabilities. You can squeeze out some additional query capabilities with a single-table approach, but it is still not comparable to any SQL database. However, for reporting, the SQL query language is extremely useful or almost essential.

One option is to copy data to an SQL database and execute queries there. However, if the database is large, this can be impractical or too expensive. A more scalable solution is to transfer data to S3 and query it with Athena using SQL, which we will explore in this article.

This approach is ideal for serverless solutions where the amount of data or cost makes an SQL database impractical. Athena is a powerful alternative and can be very cost-effective. At $5 per terabyte of queried data, it is significantly cheaper than provisioning an SQL instance capable of handling that volume. However, if you're running many queries, Athena may become expensive. Athena is best for creating offline reports. It's usually too slow for direct synchronous responses to users.

There are several ways to copy data from DynamoDB to S3, but the most useful and serverless-friendly are:

Using native full or incremental exports from DynamoDB to S3
Using EventBridge Pipes and Firehose for a near real-time copy of the data

This article focuses on the first approach. The second approach will be covered in Part 2. We will look at both solutions in the context of single-table and multiple-table designs.

...continue reading

Serverless Developer Experience is Finally Great with Lambda Live Debugger

Marko - ServerlessLife.com — Mon, 30 Sep 2024 18:27:03 +0000

Lambda Live Debugger allows you to remotely debug AWS Lambda functions, eliminating the need for time-consuming redeployment.

Lambda Live Debugger is an open-source tool that redefines serverless development by simplifying the debugging process for AWS Lambda functions. It allows developers to debug deployed Lambda functions locally, eliminating the need for redeployment and streamlining the entire workflow. With support for JavaScript, TypeScript, and numerous frameworks, Lambda Live Debugger addresses the challenges of the traditional serverless development cycle, enabling developers to bypass the tedious process of writing, deploying, and testing code, all while maintaining the same IAM permissions as if the code were running in the cloud.

How It Works

Lambda Live Debugger connects your deployed Lambda functions to your local machine through AWS IoT. It intercepts requests, routes them to your local environment for debugging, and sends responses back to the deployed Lambda. This means you can inspect and interact with your Lambda function in real-time while it remains fully integrated with its cloud environment.

In case of code changes, the tool automatically reloads the updated code without the need to redeploy or restart the debugger. TypeScript functions are automatically transpiled into JavaScript and run via Node Worker Threads.

The Easiest Way to Configure: The Wizard

One of the most convenient features of Lambda Live Debugger is its easy configuration process through the interactive wizard. Running the wizard configures key parameters such as AWS profile, region, and more with a single command:

lld -w

The wizard automatically generates a configuration file (lldebugger.config.ts) and even sets up your debugging environment in VSCode with the necessary launch configurations in .vscode/launch.json. This ensures that you can jump straight into debugging without manual configuration steps.

You can now press F5 in VSCode to start debugging, set breakpoints, and inspect variables.

Fast Switching Between Development Modes

With Lambda Live Debugger, switching between active debugging and regular execution is incredibly fast. Simply run the following command to remove the debugger:

lld -r

This detaches the debugger from your Lambda functions, allowing you to quickly resume normal operation. Turning the debugging mode back on is just as fast. In comparison, alternative solutions often require a full redeployment, wasting valuable time and resources.

Focus on Specific Lambdas

Another powerful feature is the ability to attach the debugger to only certain Lambda functions. This targeted approach allows you to concentrate solely on the part of your system you’re currently working on or experiencing issues with. By avoiding the distraction of unrelated functions, you can work more efficiently and effectively resolve problems.

Observability Mode

In serverless development, developers typically work in personal environments to avoid affecting shared environment. However, if this isn’t feasible due to organizational or technical constraints, Observability Mode offers a perfect alternative.

With Observability Mode, you can debug AWS Lambda functions without interrupting their normal operation. This mode intercepts requests and sends them to your local machine for inspection, while the Lambda continues running in the cloud as usual. The response from your machine is ignored. It's ideal for debugging in production or shared environments where you can't modify code or pause execution.

Lambda Live Debugger samples requests at regular intervals (default is every 3 seconds) to prevent system overload, enabling real-time observation without impacting performance.

Supporting Any Framework

Lambda Live Debugger out of the box supports CDK, Serverless Framework v3, AWS Serverless Application Model (SAM) and Terraform. It is also flexible enough to work with any custom setup. You can customize or provide your own list of Lambdas by modifying lldebugger.config.ts.

export default {
  ...
  getLambdas: async (foundLambdas, config) => {
    return [
      {
          // function name as deployed on AWS
          functionName: "mystack-myfunction",
          codePath: "/src/myLambda.ts",
      },
    ];
  },
} satisfies LldConfigTs;

CDK Escape Hatches + How to Export CDK to CloudFormation

Marko - ServerlessLife.com — Wed, 18 Oct 2023 05:10:11 +0000

We will look at CDK escape hatches, including the ultimate one: exporting to independent CloudFormation.

In the previous article, we built a CDK construct. However, we also want the solution to be functional on its own as a CloudFormation template. This way, you do not have to incorporate the solution into your stack. You deploy a new one and point to the existing SNS topic you use for CloudWatch Alarm notification. We do not want to write CloudFormation from scratch but to reuse the CloudFormation that CDK produces. In this article, we will look at how to convert CDK to clean CloudFormation without CDK metadata and the weird naming that CDK produces. Along the way, we will learn some really useful CDK tricks.

Why convert to CloudFormation and ship independently of CDK?

There are multiple reasons why people may prefer exported CloudFormation over CDK.

Reuse already-built constructs/solutions. That is our reason.
CDK has some obvious downsides, and having an escape hatch of converting CloudFormation can be useful.
Culture war with (Dev)Ops guys. The real developers, some would say, write every line of CloudFormation by themselves. Anything else is “unworthy of the title developer.”
The requirement is to produce CloudFormation, but the speed of the development with CDK is unmatched.

I highly discourage having a default solution that converts CDK to CloudFormation. That should be the last escape hatch. CDK brings a lot of benefits and features, and a lot of them cannot be replicated by just converting to CloudFormation. If the “culture war” is the cause of this approach, it would be better to sit down with the opposite side and do an unbiased evaluation of each approach. The end goal is to build a good product with the least resources and not to win culture wars.

We can export to CloudFormation like this:

cdk synth > my_cloudformation.yaml

You do not need anything else. But this approach has several issues:

CloudFormation has a lot of CDK metadata.
Logical names have random characters in the postfix.
Assets are not dropped to any appropriate S3.

In our case, we also want to extend CloudFormation with CloudFormation parameters for the ARN of the SNS topic.

Continue reading on www.serverlesslife.com...

Tips and Tricks for Developing CDK Construct using Projen

Marko - ServerlessLife.com — Wed, 11 Oct 2023 05:36:06 +0000

Projen is an essential tool for creating CDK constructs. But it is opinionated. We will look into tips and tricks on how to overcome its constraints.

Projen is a multipurpose project generator. Among other things, it can be used for building a CDK construct.

Why would you need a special tool like Projen for creating a CDK construct?

Creating a CDK construct is as easy as extending a Construct class:

export class LambdaErrorSnsSender extends Construct {
  constructor(scope: Construct, id: string, props: LambdaErrorSnsSenderProps) {
    super(scope, id);
    …
  }
}

If you are building a CDK construct that you intend to use in the same solution, you do not need anything else. But if you want to ship the construct to open source repos: Npm, Maven, Pypi, Nuget, or Go, you must transpile your code construct from TypeScript to other languages, package them, and deploy them to the desired repo. And you would need to do that in CI/CD. This is where Projen comes in. It sets up the whole environment with all the features and bells and whistles that you may need.

The Projen provides the following features when building a CDK construct:

Compile, lint, and test the code.
Use JSII to produce library artifacts for all target languages.
Determine the next minor/patch version based on conventional commits.
A changelog entry is generated based on the commit history.
Packages are published to all target package managers.

Continue reading on www.serverlesslife.com...

Improving CloudWatch Alarms for Lambda Errors

Marko - ServerlessLife.com — Wed, 04 Oct 2023 05:44:03 +0000

A simple solution to improve the CloudWatch alarm to receive Lambda error details by email. Available as CDK construct or as CloudFormation.

AWS CloudWatch is not the best service for monitoring your system. It has a ton of features, but many of them are awkward to use. But at the same time, it is baked into AWS, and you do not have to look for something else. And for a large number of solutions, it is good enough.

One of the not-so-nice things is notifying of Lambda errors. Typically, you would attach an Alarm to the Lambda error metric. The Alarm would send a message to SNS, which would send it to your email or SMS. That is a relatively common way, but not the only one. One benefit of this approach is that you do not get a ton of messages. You just get one for the Alarm being in the error state.

But this notification does not contain any details on an error. You will have to open the AWS console, find the appropriate log group, open CloudWatch Logs Insights, write a query, and after a few minutes, you will have your error message, which quite possibly is an unimportant one-time occurrence of some timeout. Of course, you can simplify this process, but wouldn't it be great to get a sample of errors by email? Most of the systems for monitoring and logging, like Sentry, provide that out of the box.

I will present a simple solution for getting error messages by email. It is great for smaller projects when you do not want to configure other error-logging solutions or for older systems where you do not wish to alter them just because of that.

The solution is in two forms:

CDK construct If you are building your system with CDK (or SST). Available for TypeScript, Java, C#, Python, and Go.
CloudFormation For existing solutions, so you do not have to modify them. You deploy and point to the existing SNS used for CloudWatch alarms.

How does it work?

Lambda is subscribed to the SNS topic where you receive your alarms. There is a message body subscription filter that limits errors based on the Lambda error metric. You must change the filter if you defied your metric in some other way, not the default one.
Lambda analyzes the message, finds a log of the failed Lambda, and queries the log group for the period that the metric was configured, plus some additional safety time, so we do not miss that error message. It extracts just a number of errors that can fit in one SNS message.
Lambda sends errors to the same SNS that you use for alerts. So, apart from the Alarm message for changing the error state, you will receive an additional one with detailed error messages.

Continue reading on www.serverlesslife.com…

ServerlessSpy—Gain Insight into the Cloud and Write Serverless Tests with Ease

Marko - ServerlessLife.com — Tue, 26 Sep 2023 05:40:25 +0000

ServerlessSpy is a CDK-based library for writing integration tests on AWS serverless, and it comes with a web console to monitor events in real time.

Writing tests for serverless is challenging. Unit tests often do not provide much value because all services need to be mocked. Integration tests that run on the real cloud infrastructure are the preferred way to test such a system. But integration tests are hard to write, and they are slow to execute. A serverless system is usually built as an asynchronous event-driven system. That means that you put an event in on one side, and after some time, you get some output on the other side. You do not know when, so you have to keep checking. That is slow. At the same time, no other tests can usually run because they will mess up your data. The last issue is that you often have to save the message in some storage just for the integration test to be able to inspect the message.

That's why I created a ServerlessSpy, which resolves the problems mentioned above. It provides a CDK construct that creates infrastructure to intercept events in Lambda, SNS, SQS, EventBridge, DynamoDB, and S3, and sends it to a testing library via API Gateway WebSocket. The testing library subscribes to events so that tests can be executed fast without checking/retrying if the process has finished. You do not have to build additional infrastructure to temporarily store the events. Tests can also run in parallel because you can filter events to receive only the ones meant for your test case.

ServerlessSpy can be used for more than writing integration tests. A special web console can receive events from WebSocket. The console enables you to inspect events in real time and see what is happening in the cloud. Some say it is even more useful than the part for writing integration tests.

Writing integration tests for #serverless used to be a tedious job. #ServerlessSpy with the magic of #CDK and #TypeScript makes writing integration tests fast and pleasant.

Key benefits:

Easy to write tests that are strongly typed thanks to TypeScript.
Tests are executed much FASTER. No need to write tests in a way to periodically check if the process has finished because all events are pushed to the testing library.
Tests can run in parallel if you use conditions and filter events specific to your test. This drastically reduces the execution time of the CI/CD process.
Web console enables you to see all events in real time. Debugging has never been easier. Search for events is also supported (with regular expression).

Continue reading on www.serverlesslife.com...

OpenAPI + Zod + API Gateway + SST = Turbo Productivity

Marko - ServerlessLife.com — Wed, 20 Sep 2023 06:37:33 +0000

How to boost productivity with OpenAPI schema, Zod library, and client-generated code. Included is a sample serverless app built with SST/CDK.

"Don't repeat yourself" (DRY) is one of the main principles of software development. But we keep on breaking it by rewriting the data structure on each layer. In this article, we'll explore the method of enhancing our productivity through the utilization of OpenAPI schema, the Zod library, and the generation of client code, all aimed at reusing our types, schemas, and structures. l will bundle everything into a sample AWS serverless application built with the SST framework (which uses CDK). The solution also takes into account that you do not want to have exactly the same types everywhere. The Zod library nicely solves the problem and allows you to mix and match types.

> We keep breaking the "Don't repeat yourself" (DRY) principle by rewriting the data structure on each layer.

When you are creating an API and an application that consumes it, you need to (re)create types/schema for each layer:

data exchange = OpenAPI, GraphQL
client that consume it
API validation logic
business logic

Continue reading on www.serverlesslife.com...