Skip to content
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

Migrate from aws-sdk-go to aws-sdk-go-v2 #103

Closed
onno-vos-dev opened this issue Mar 5, 2024 · 2 comments
Closed

Migrate from aws-sdk-go to aws-sdk-go-v2 #103

onno-vos-dev opened this issue Mar 5, 2024 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@onno-vos-dev
Copy link
Member

onno-vos-dev commented Mar 5, 2024

Opening this issue for transparency and as an announcement to the community that we will continue to support aws-elixir and aws-erlang into the future of AWS SDK v2! 🎉📢

AWS announced that AWS SDK Go (v1) will go into maintenance mode as of July 31, 2024. ⚠️ From that point on, the SDK will not receive API updates for new or existing services, or be updated to support new regions. This is problematic for aws-beam as we depend on the aws-sdk-go 🛠️ to generate the code for aws-elixir and aws-erlang.

This issue will encapsulate the work of migrating to aws-sdk-go-v2 instead. 🔄

The following goals must be upheld: ✔️

  • Interfaces to the clients that have integrated with either aws-elixir and aws-erlang MAY NOT change at all. Any changes MUST BE transparent and happen "under the hood" 🕵️
  • NO new non-backwards compatible features should be included in order to make the migration transparent to the clients 🚫
  • NO unexpected diff may occur in either repo. ❌ Semantically, they should produce the same code with some exceptions:
    • SuccessStatusCode is not always defined yet the new repo ensures a default of 200 whereas now we have undefined. This is broken and we can sneak in the fix in this as part of this work 🛠️
    • Some paths have changed as part of the new specification. It may be that we generated old code erroneously or misunderstood the spec. Either way, the paths will be fixed as part of the v2 API. This should in theory be fine 👍🔧
    • Docs have changed, this is expected and has no impact on compiled code. This is acceptable. 📚
@onno-vos-dev onno-vos-dev self-assigned this Mar 5, 2024
@onno-vos-dev
Copy link
Member Author

onno-vos-dev commented Mar 5, 2024

@jadeallenx @philss @robertoaloi @josevalim @jkakar

This work has been ongoing inside a private repo under the aws-beam organisation (aws-codegen-v2) in order to be able to start nightly builds and compare diffs on a regular basis to ensure the above set of goals are upheld. Once ready, the commit(s) will be ported over to this repo.

The current state of this work is that we have successfully migrated and have a working version of aws-erlang with a minimal diff as per the goals above. We will start to look into aws-elixir and the diff generated there shortly to see if/what has changed there.

aws-beam/aws-erlang#148 has been sneaked in but since that's a backwards compatible change, I figured we could wait with resolving the issue until we roll this v2 out. It's easy enough to backport in case the need arises.

onno-vos-dev added a commit that referenced this issue Mar 8, 2024
Goal here has been to minimize the diff in aws-elixir and aws-erlang to a bare minimum.

Some minor diffs were unavoidable and deemed acceptable
* Fix SuccessStatusCode to always be 200 if not provided by AWS in the API
  * Before SuccessStatusCode was set to undefined/nil. This was unhandled and would've caused errors.
* Fix aws-erlang/issues/148 to allow send_body_as_binary & receive_body_as_binary to be sent in as options
  * The default remains the same, but certain APIs may require a change of the default depending on the in- or output
* Drop abbreviation from metadata. It is no longer available in aws-sdk-go-v2 and unused in aws-elixir
* Slight formatting changes on aws-erlang docs as the new docs contain a lot more newlines and hence cause more noise
* Uri Paths may have changed. This should not impact the clients. It was likely broken in the aws-sdk-go
* QueryMap may have changed but should not impact the client. It was likely broken in the aws-sdk-go
* Docs have changed (massively) since almost all documentation has been updated

Co-authored-by: Amin Arria <[email protected]>
Co-authored-by: Gustavo Mora González <[email protected]>
Co-authored-by: Philip Sampaio <[email protected]>
onno-vos-dev added a commit that referenced this issue Mar 8, 2024
Goal here has been to minimize the diff in aws-elixir and aws-erlang to a bare minimum.

Some minor diffs were unavoidable and deemed acceptable
* Fix SuccessStatusCode to always be 200 if not provided by AWS in the API
  * Before SuccessStatusCode was set to undefined/nil. This was unhandled and would've caused errors.
* Fix aws-erlang/issues/148 to allow send_body_as_binary & receive_body_as_binary to be sent in as options
  * The default remains the same, but certain APIs may require a change of the default depending on the in- or output
* Drop abbreviation from metadata. It is no longer available in aws-sdk-go-v2 and unused in aws-elixir
* Slight formatting changes on aws-erlang docs as the new docs contain a lot more newlines and hence cause more noise
* Uri Paths may have changed. This should not impact the clients. It was likely broken in the aws-sdk-go
* QueryMap may have changed but should not impact the client. It was likely broken in the aws-sdk-go
* Docs have changed (massively) since almost all documentation has been updated

Co-authored-by: Amin Arria <[email protected]>
Co-authored-by: Gustavo Mora González <[email protected]>
Co-authored-by: Philip Sampaio <[email protected]>
onno-vos-dev added a commit that referenced this issue Mar 9, 2024
…go-to-aws-sdk-go-v2

Issue #103: Migrate from aws-sdk-go to aws-sdk-go-v2
@onno-vos-dev
Copy link
Member Author

Completed in: #104

@onno-vos-dev onno-vos-dev added the enhancement New feature or request label Mar 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant