It will go just fine. To quote the AWS documentation:

The current version of the Amazon S3 API is 2006-03-01.

The API hasn’t had a backwards incompatible change in 14 years, at least according to its docs. ExAws deprecation is more about forward compatibility with new AWS services and less about backward compatibility with existing ones.

Write your code without create any coupling with your storage system. So if you want to change to another lib, you will not change any of your business stuff. In that way, you’ll be ok to use ExAws even if you think it will be deprecated.

But as said @benwilson512 aws api doesn’t break backward compatibilty. You should be ok for the next decade (or something like that).

I ended up rolling my own, and I decided to put it in its own lib. I’m not sure if I’ll expand it enough to merit releasing a package, but if anyone’s interested the source is on Github:

It takes a lot of inspiration from Ruby’s Shrine, but with the spirit (patterns) of Elixir. It only handles url -> local storage right now. I’ll at least be adding binary, and Plug.Upload support, probably Ecto support.

Manage file attachement by myself and use separate storage lib depending of the need (e.g. s3 lib).
File attachment is really easy in Phoenix.

It appears that the link has changed:

https://github.com/elixir-capsule/capsule