Homepage
Powertools for AWS Lambda (TypeScript) is a developer toolkit to implement Serverless best practices and increase developer velocity.
You can use Powertools for AWS Lambda in both TypeScript and JavaScript code bases.
Features
Adopt one, a few, or all industry practices. Progressively.
Support this projectBecome a public reference customer, share your work, contribute, use Lambda Layers, etc.
Available languages
Powertools for AWS Lambda is also available in other languages
Features¶
Powertools for AWS Lambda (TypeScript) is built as a modular toolkit, so you can pick and choose the utilities you want to use. The following table lists the available utilities, and links to their documentation.
| Utility | Description |
|---|---|
| Tracer | Decorators and utilities to trace Lambda function handlers, and both synchronous and asynchronous functions |
| Logger | Structured logging made easier, and a middleware to enrich structured logging with key Lambda context details |
| Metrics | Custom Metrics created asynchronously via CloudWatch Embedded Metric Format (EMF) |
| Event Handler - AppSync Events | Event Handler for AWS AppSync real-time events |
| Parameters | High-level functions to retrieve one or more parameters from AWS SSM Parameter Store, AWS Secrets Manager, AWS AppConfig, and Amazon DynamoDB |
| Idempotency | Class method decorator, Middy middleware, and function wrapper to make your Lambda functions idempotent and prevent duplicate execution based on payload content. |
| Batch Processing | Utility to handle partial failures when processing batches from Amazon SQS, Amazon Kinesis Data Streams, and Amazon DynamoDB Streams. |
| JMESPath Functions | Built-in JMESPath functions to easily deserialize common encoded JSON payloads in Lambda functions. |
| Parser | Utility to parse and validate AWS Lambda event payloads using Zod, a TypeScript-first schema declaration and validation library. |
| Validation | JSON Schema validation for events and responses, including JMESPath support to unwrap events before validation. |
Examples¶
You can find examples of how to use Powertools for AWS Lambda (TypeScript) in the examples directory, which contains both code snippets for specific use cases, as well as a full example application.
If instead you want to see Powertools for AWS Lambda (TypeScript) in a more involved context, check the Powertools for AWS workshop where we demonstrate how to use toolkit in a more complex application.
Support Powertools for AWS¶
There are many ways you can help us gain future investments to improve everyone's experience:
- Become a public reference
Add your company name and logo on our landing page, documentation, and README files.
Share your workBlog posts, video, and sample projects about Powertools for AWS Lambda.
Join the communityConnect, ask questions, and share what features you use.
Becoming a reference customer¶
Knowing which companies are using this library is important to help prioritize the project internally. The following companies, among others, use Powertools:
Using Lambda Layers¶
Layers help us understand who uses Powertools for AWS Lambda (TypeScript) in a non-intrusive way.
When using Layers, you can add Powertools for AWS Lambda (TypeScript) as a dev dependency to not impact the development process. For Layers, we pre-package all dependencies, compile and optimize for storage.
Tenets¶
These are our core principles to guide our decision making.
- AWS Lambda only. We optimise for AWS Lambda function environments and supported runtimes only. Utilities might work with web frameworks and non-Lambda environments, though they are not officially supported.
- Eases the adoption of best practices. The main priority of the utilities is to facilitate best practices adoption, as defined in the AWS Well-Architected Serverless Lens; all other functionality is optional.
- Keep it lean. Additional dependencies are carefully considered for security and ease of maintenance, and prevent negatively impacting startup time.
- We strive for backwards compatibility. New features and changes should keep backwards compatibility. If a breaking change cannot be avoided, the deprecation and migration process should be clearly defined.
- We work backwards from the community. We aim to strike a balance of what would work best for 80% of customers. Emerging practices are considered and discussed via Requests for Comment (RFCs)
- Progressive. Utilities are designed to be incrementally adoptable for customers at any stage of their Serverless journey. They follow language idioms and their community’s common practices.
