Additional features and improvements

[jpbourgeon]

Building the benchmark inspired me with some ideas for additional features and improvements.
See threads below:

• Optimize HTTP requests
• Handle API retries gracefully
• Use memoization
• Dependency curation
• Extended benchmark

[jpbourgeon]

Optimize HTTP requests

The SDK sends HTTP requests to the AWS API to perform operations. To optimize performance, we should consider using techniques such as HTTP connection pooling and persistent connections where applicable. AWS SDK offers opt-in solutions to connection pooling (connection reuse environment variable) and persistent connections (when declaring clients outside the handler).

[sam-goodwin]

Perhaps we can support plugging in your own connection pooling logic? Not sure what could be done beyond using http.Agent

[jpbourgeon]

Handle API retries gracefully

AWS SDKs handle error retries with exponential backoff and jitter https://docs.aws.amazon.com/general/latest/gr/api-retries.html, https://aws.amazon.com/fr/blogs/architecture/exponential-backoff-and-jitter/

[jpbourgeon]

Use memoization

The SDK includes several utility functions, such as resolveEndpoint() and resolveXAmzTarget(), that could benefit from memoization. Memoization can help improve the performance of these functions by caching the results of previous calls and returning them for subsequent calls with the same arguments.

[jpbourgeon]

Dependency curation

Limit external dependencies. When they are needed, carefully choose the fastest, smallest, safest and well maintained.
For example, we could try to optimize the parsing of XML responses: itty-aws uses the @rgrove/parse-xml library to parse XML responses from the AWS API. Parsing XML can be a computationally expensive operation, especially for large responses. We should experiment with using faster alternatives like fast-xml-parser or even implementing custom parsing logic where applicable.

[jpbourgeon]

Extended benchmark

itty-aws should emit events or provide hooks for latency measurement. We should extend our benchmarking to more complex situations: heavy requests, longer executions, many calls and services from the same function, etc.