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 project
Become 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) |
| 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 work
Blog posts, video, and sample projects about Powertools for AWS Lambda.
-
Join the community
Connect, 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.