Skip to content

awspring#595 Add module for aws ses API v2 #1356

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

rmschots
Copy link

@rmschots rmschots commented Mar 9, 2025

📢 Type of change

  • Bugfix
  • New feature
  • Enhancement
  • Refactoring

📜 Description

Add a module to allow use of SES API v2.

💡 Motivation and Context

Amazon SES API v1 accepts messages up to 10MB in size including any images and attachments that are part of the message. SES API v2 accepts up to 40MB.
Issue #595
Alternative solution to #1336.
This solution guarantees no breaking changes with previous versions, and allows using the v2 API instead.

💚 How did you test it?

  • Same tests as the v1 API, as the functionality is the same.
  • Manually tested a new sample application, using localstack pro, as only the pro version supports ses v2.

📝 Checklist

  • I reviewed submitted code
  • I added tests to verify changes
  • I updated reference documentation to reflect the change
  • All tests passing
  • No breaking changes

🔮 Next steps

@github-actions github-actions bot added type: documentation Documentation or Samples related issue type: dependency-upgrade Dependency version bump type: maintenance Repository maintenance not affecting production files labels Mar 9, 2025
@maciejwalkowiak
Copy link
Contributor

Thanks @rmschots for a PR. Perhaps it could be improved to reduce the duplication, as these classes from V1 and V2 are pretty much the same with small differences. Perhaps both V1 and V2 could live in single module with optional dependencies to SES SDKs, which would allow us to have an abstract base classes for two versions, and then there would be two starters for V1 and V2 that would bring related SDKs? What do you think about it? cc @MatejNedic

@maciejwalkowiak maciejwalkowiak added the status: waiting-for-feedback Waiting for feedback from issuer label Mar 15, 2025
@rmschots
Copy link
Author

@maciejwalkowiak I implemented the separate module based on the feedback on #1336 (comment).
Maybe best that there is a consensus on the solution before people create another PR.

@MatejNedic
Copy link
Member

@maciejwalkowiak Personally I would prefer duplication since SDK is different. We can slowly than deprecate V1 version much cleaner, specific feature and implementations can be handled much better and so on.

I would go with split. Let me take a look in code and think about it, will make a review in following days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-feedback Waiting for feedback from issuer type: dependency-upgrade Dependency version bump type: documentation Documentation or Samples related issue type: maintenance Repository maintenance not affecting production files
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants