Feature request: Middleware Chain API for Powertools Utilities

[phipag]

Use case

Currently, Powertools for AWS Lambda (Java) provides individual utilities like Logging, Tracing, Metrics, and other features through AspectJ annotations and static methods. While effective, this approach lacks a unified and modern functional interface for applying multiple Powertools utilities to Lambda handlers without relying on AspectJ annotations.

Developers need a solution that offers:

• A unified functional API to compose multiple Powertools features (logging, tracing, metrics, validation, etc.)
• Type-safe middleware composition that works across all Lambda handler types (RequestHandler, RequestStreamHandler, etc.)
• Clean separation between business logic and cross-cutting concerns without AspectJ dependencies
• Flexible composition allowing different orders and combinations of middlewares
• Modern Java functional programming patterns that feel idiomatic to Java developers

This would provide an alternative to the current AspectJ annotation-based approach while maintaining the same powerful utility features.

Solution/User Experience

Introduce a middleware chain API that allows functional composition of Powertools features. The design below suggests an implementation of the Chain of Responsibility software design pattern:

@FunctionalInterface
public interface Middleware<T, R>{
 R apply(T input, Context context, BiFunction<T, Context, R> next);
}

public class MiddlewareChain<T, R>{
 public MiddlewareChain<T, R> use(Middleware<T, R> middleware){/* ... */ }
 public R execute(T input, Context context, BiFunction<T, Context, R> handler){/* ... */ }
}

public class PowertoolsMiddlewares{
 public static <T, R> Middleware<T, R> logging(){/* ... */ }
 public static <T, R> Middleware<T, R> tracing(String serviceName){/* ... */ }
 public static <T, R> Middleware<T, R> metrics(String namespace){/* ... */ }
}

Usage example:

public class OrderHandler implements RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent>{
 
 private final MiddlewareChain<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent> chain = 
 new MiddlewareChain<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent>()
 .use(PowertoolsMiddlewares.logging())
 .use(PowertoolsMiddlewares.tracing("OrderService"))
 .use(PowertoolsMiddlewares.metrics("Orders"));
 
 @Override
 public APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent input, Context context){
 return chain.execute(input, context, this::processOrder);
 }
 
 private APIGatewayProxyResponseEvent processOrder(APIGatewayProxyRequestEvent request, Context context){
 // Business logic here
 return APIGatewayProxyResponseEvent.builder()
 .withStatusCode(200)
 .withBody("{\"message\": \"Order processed\"}")
 .build();
 }
}

Benefits:

• Type-safe: Works with any Lambda handler type through generics
• Composable: Middlewares can be combined in any order
• Functional: Leverages modern Java functional programming patterns
• Consistent: Same API works for RequestHandler, RequestStreamHandler, etc.
• Flexible: Easy to add custom middlewares or modify the chain

Alternative solutions

Decorator pattern: Wrap handlers with individual decorators

• Pros: Object-oriented approach, familiar pattern
• Cons: More verbose, harder to compose multiple decorators, requires creating wrapper classes for each feature

Aspect-Oriented Programming (AOP): Frameworks like Spring AOP are too heavy for Lambda environments and introduce additional dependencies that may not be suitable for serverless architectures.

Acknowledgment

• This feature request meets Powertools for AWS Lambda (Java) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, TypeScript, and .NET

---

Disclaimer: After creating an issue, please wait until it is triaged and confirmed by a maintainer before implementing it. This will reduce amount of rework and the chance that a pull request gets rejected.

Future readers: Please react with 👍 and your use case to help us understand customer demand.

[phipag]

To be able to support this, we need to add a non-AspectJ interface to all utilities which don't have one yet. I include some sub-issues in this issue.