Maintenance: Audit & reduce public API surface area

[scottgerring]

Summary

As part of the V2 improvements we have an opportunity to work on public-facing API changes. We should reflect on our current API surface and where there is room for improvement in terms of what is exposed to the user. Where we make a change from V1, we should document a migration path.

Why is this needed?

As it stands we have quite a large API surface area that can 1/ make it difficult for customers to use the API ("which one of these options should I use to interact with this module?) and 2/ make it difficult to maintain the modules, as any public API cannot be changed.

Which area does this relate to?

No response

Solution

No response

Acknowledgment

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

[scottgerring]

This has been done for some modules:

• Batch: feat: Add Batch Processor module #1317
• Large messages: feat: large message in SQS and SNS #1310
• Metrics: Feature request: support high resolution metrics #1041
• Logging: feat(v2): new logging module #1435

This will be done for the other modules:

• Idempotency: Maintenance: Split powertools-idempotency into sub-modules #1467
• Parameters: chore(v2): Split parameters module up by parameter provider #1403
• Tracing: Maintenance: V2 updates - review interface & propose improvements for Tracing module #1468
• Validation: Maintenance: V2 updates - review interface & propose improvements for Validation module #1469
• Serialization: Maintenance: V2 updates - review interface & propose improvements for Serialization module #1470