Powertools for AWS Lambda (TypeScript) (original) (raw)

Roadmap

Overview¶

Our public roadmap outlines the high level direction we are working towards. We update this document when our priorities change: security and stability are our top priority.

Key areas¶

Security and operational excellence take precedence above all else. This means bug fixing, stability, customer's support, and internal compliance may delay one or more key areas below.

We may choose to reprioritize or defer items based on customer feedback, security, and operational impacts, and business value.

Event Handler REST (p0)¶

This is a roadmap item that we carry forward from 2024 and involves the creation of a new utility for customers to work with REST APIs built on AWS Lambda, and Amazon API Gateway REST and HTTP APIs, Application Load Balancer (ALB), Lambda Function URLs, and VPC Lattice. It's one of the most requested features in terms of feature parity from our customers.

You can follow the progress of this feature in the Event Handler REST milestone. Below are some of the key macro tasks that we will be working on:

• Explore pros & cons of whether to build atop lean frameworks (e.g., Hono) or from scratch
• RFC to discuss initial thoughts and feasibility for TS/JS ecosystem
• Support for API Gateway REST API resolver
• Support for API Gateway HTTP API resolver
• Support for Lambda Function URL resolver
• Support for Application Load Balancer resolver
• Support for VPC Lattice resolver
• Support for Data Validation (e.g., Zod)
• Support for OpenAPI generation
• Support for Middlewares
• Support for Compression
• Support for Binary responses
• Support for custom serializer
• Support for injecting request details (consider not doing globals like Python legacy)
• Support for Router (multi-file routes)

Feature parity (p1)¶

To close the gap between Powertools for AWS Lambda (Python) and Powertools for AWS Lambda (TypeScript), we will focus our efforts on adding targeted features that are currently missing from the TypeScript version. These include (but are not limited to):

Logger¶

• Ability to add a correlation ID to logs via decorator/middleware
• Ability to pretty print stack traces
• Ability to buffer logs
• Ability to refresh debug log sampling rate via decorator/middleware

Event Handler¶

In addition to the Event Handler REST feature mentioned above, we will also be working on the following:

• Implement resolver for Amazon Bedrock Agents Functions
• Implement resolver for AWS AppSync Events API
• Implement resolver for Amazon Bedrock Agents OpenAPI
• Create RFC for AppSync GraphQL resolver

Validation¶

For the Validation utility, we'll experiment with a community-driven approach to building a new Powertools for AWS Lambda utility.

• Standalone validation utility
• Class method decorator validation
• Middy.js middleware validation
• Documentation

Other utilities¶

• Support for Valkey- and Redis OSS-compatible cache backends for Idempotency

Governance & Advanced Use Cases (p2)¶

To streghten our offering for more advanced customers as well as enterprises, we will be working on a set of activities that will help us better support their needs and practices. These include:

• Publish Lambda layers to GovCloud
• Publish Lambda layers to China regions
• Improve OSS supply chain posture (Q2) by making sure we're auditing our dependencies for compatible licenses and include NOTICE files in our Lambda layers
• Create a new "Advanced Use Cases" section in the docs - to help customers with more complex use cases, such as running Powertools for AWS Lambda in container environments
• Set up CI/CD for performance testing
• Improve performance of our core utilities
• Improve performance overhead of Lambda layers
• Publish SSM Parameters to lookup Lambda layers ARNs

To ensure we are attracting tomorrow's customers as well as new contributors to the project, we will be working on a set of activities that will help us better engage with the community and new customers. These include:

• Create a new "Getting Started" guide in the docs
• Further improve the "Contributing" & "How to find contributions" pages
• Surface contribution opportunities in Discord & other community channels
• Improve release notes announcements in Discord & other community channels
• We will also attempt to create a community-developed new utility (see Validation above)

Missing something?¶

You can help us prioritize by upvoting existing feature requests, leaving a comment on what use cases it could unblock for you, and by joining our discussions on Discord.

Roadmap status definition¶

graph LR
    Ideas --> Backlog --> Work["Working on it"] --> Merged["Coming soon"] --> Shipped

Visual representation

Within our public board, you'll see the following values in the Status column:

• Ideas. Incoming and existing feature requests that are not being actively considered yet. These will be reviewed when bandwidth permits.
• Backlog. Accepted feature requests or enhancements that we want to work on.
• Working on it. Features or enhancements we're currently either researching or implementing it.
• Coming soon. Any feature, enhancement, or bug fixes that have been merged and are coming in the next release.
• Shipped. Features or enhancements that are now available in the most recent release.

Tasks or issues with empty Status will be categorized in upcoming review cycles.

Process¶

graph LR
    PFR[Feature request] --> Triage{Need RFC?}
    Triage --> |Complex/major change or new utility?| RFC[Ask or write RFC] --> Approval{Approved?}
    Triage --> |Minor feature or enhancement?| NoRFC[No RFC required] --> Approval
    Approval --> |Yes| Backlog
    Approval --> |No | Reject["Inform next steps"]
    Backlog --> |Prioritized| Implementation
    Backlog --> |Defer| WelcomeContributions["help-wanted label"]

Visual representation

Our end-to-end mechanism follows four major steps:

• Feature Request. Ideas start with a feature request to outline their use case at a high level. For complex use cases, maintainers might ask for/write a RFC.
  • Maintainers review requests based on project tenets, customers reaction (👍), and use cases.
• Request-for-comments (RFC). Design proposals use our RFC template to describe its implementation, challenges, developer experience, dependencies, and alternative solutions.
  • This helps refine the initial idea with community feedback before a decision is made.
• Decision. After carefully reviewing and discussing them, maintainers make a final decision on whether to start implementation, defer or reject it, and update everyone with the next steps.
• Implementation. For approved features, maintainers give priority to the original authors for implementation unless it is a sensitive task that is best handled by maintainers. See Maintainers document to understand how we triage issues and pull requests, labels and governance.

Disclaimer¶

The Powertools for AWS Lambda (TypeScript) team values feedback and guidance from its community of users, although final decisions on inclusion into the project will be made by AWS.

We determine the high-level direction for our open roadmap based on customer feedback and popularity (👍🏽 and comments), security and operational impacts, and business value. Where features don’t meet our goals and longer-term strategy, we will communicate that clearly and openly as quickly as possible with an explanation of why the decision was made.

FAQs¶

Q: Why did you build this?

A: We know that our customers are making decisions and plans based on what we are developing, and we want to provide our customers the insights they need to plan.

Q: Why are there no dates on your roadmap?

A: Because job zero is security and operational stability, we can't provide specific target dates for features. The roadmap is subject to change at any time, and roadmap issues in this repository do not guarantee a feature will be launched as proposed.

Q: How can I provide feedback or ask for more information?

A: For existing features, you can directly comment on issues. For anything else, please open an issue.