You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/build_recipes/performance-optimization.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,6 +7,8 @@ description: Optimize Lambda functions for better performance and reduced costs
7
7
8
8
Optimize your Lambda functions for better performance, reduced cold start times, and lower costs. These techniques help minimize package size, improve startup speed, and reduce memory usage.
9
9
10
+
Always validate your function's behavior after applying optimizations to ensure an optimization hasn't introduced any issues with your packages. For example, removal of directories that appear to be unnecessary, such as `docs`, can break some libraries.
11
+
10
12
## Reduce cold start times
11
13
12
14
1.**Minimize package size** by excluding unnecessary files
You can use Pydantic's `Field(discriminator="...")` with union types to create discriminated unions (also known as tagged unions). This allows the Event Handler to automatically determine which model to use based on a discriminator field in the request body.
1.`Field(discriminator="action")` tells Pydantic to use the `action` field to determine which model to instantiate
440
+
2.`Body()` annotation tells the Event Handler to parse the request body using the discriminated union
441
+
431
442
#### Validating responses
432
443
433
444
You can use `response_validation_error_http_code` to set a custom HTTP code for failed response validation. When this field is set, we will raise a `ResponseValidationError` instead of a `RequestValidationError`.
@@ -1482,6 +1493,9 @@ Each endpoint will be it's own Lambda function that is configured as a [Lambda i
1482
1493
1483
1494
You can test your routes by passing a proxy event request with required params.
1484
1495
1496
+
???+ info
1497
+
Fields such as headers and query strings are always delivered as strings when events reach Lambda. When testing your Lambda function with local events, we recommend using the sample events available in our [repository](https://github.com/aws-powertools/powertools-lambda-python/tree/develop/tests/events).
1498
+
1485
1499
=== "API Gateway REST API"
1486
1500
1487
1501
=== "assert_rest_api_resolver_response.py"
@@ -1545,14 +1559,3 @@ You can test your routes by passing a proxy event request with required params.
1545
1559
Chalice is a full featured microframework that manages application and infrastructure. This utility, however, is largely focused on routing to reduce boilerplate and expects you to setup and manage infrastructure with your framework of choice.
1546
1560
1547
1561
That said, [Chalice has native integration with Lambda Powertools](https://aws.github.io/chalice/topics/middleware.html){target="_blank" rel="nofollow"} if you're looking for a more opinionated and web framework feature set.
1548
-
1549
-
**What happened to `ApiGatewayResolver`?**
1550
-
1551
-
It's been superseded by more explicit resolvers like `APIGatewayRestResolver`, `APIGatewayHttpResolver`, and `ALBResolver`.
1552
-
1553
-
`ApiGatewayResolver` handled multiple types of event resolvers for convenience via `proxy_type` param. However,
1554
-
it made it impossible for static checkers like Mypy and IDEs IntelliSense to know what properties a `current_event` would have due to late bound resolution.
1555
-
1556
-
This provided a suboptimal experience for customers not being able to find all properties available besides common ones between API Gateway REST, HTTP, and ALB - while manually annotating `app.current_event` would work it is not the experience we want to provide to customers.
1557
-
1558
-
`ApiGatewayResolver` will be deprecated in v2 and have appropriate warnings as soon as we have a v2 draft.
0 commit comments