Hey folks,

I’m the author and maintainer of ExAws, a library for interacting with AWS APIs in a flexible and convenient fashion. This library plays an important role in people’s applications and, thanks to the many contributions and advice I have received, I think it embodies some good API library design principles.

Unfortunately, I’ve been doing at best a mediocre job as its maintainer. This is for three reasons:

1. I don’t have enough time these days
2. AWS is gigantic.
3. ExAws is gigantic

There isn’t a lot I can do about #1 or #2 at the moment, but I have an idea about #3 that may help:

ExAws Architecture Recap

To review briefly, ExAws is built around 4 core operation structs, that represent the broad categories of API design that AWS uses: JSON, Query, RestQuery, and S3 (yes of course S3 is its own beast, AWS). Each of these operations implements the ExAws.Operation protocol, which handles the common request logic.

ExAws has resisted using code generation to build its APIs because since we have these structs, you can basically use any service AWS has so long as you supply the config, and build your operation. This could be a bit easier, but code generated functions don’t really bring anything to the table.

Finally, there are individual service modules that exist as Elixir friendly wrappers around each API action and return operation structs.

The Problem

It’s these service modules that are the issue. We’ve got quite a lot of them at this point, and they’re all pretty big, some are huge. Many were contributed (thank you!) but because of that I don’t know much of anything about the AWS service, and after I time I can’t remember anything about the code specific to that service.

If someone makes a PR to update that service, I am ill-equipped to make a good review of it.

v2.0 Proposal

I want to make an ex-aws organization on github. Within that, there would be the following libraries:

• ex-aws/core: This would house the operation structs, the operation protocol, common request logic, signing logic, and so forth. I would be the primary maintainer of this library, and work to improve the documentation on how to use the operation structs, and how to contribute. On hex this would become :ex_aws_core

• ex-aws/s3: This would be an example service library that I would also maintain, since it is essential to what we do at Cargosense, and I’m the original author. It would depend on :ex_aws_core, and only contain the specific S3 service module.

• ex-aws/$SERVICE: There are going to be services that I won’t personally maintain. I simply don’t have the time or knowledge to do so. I will give those who want to maintain $SERVICE full commit access to the repo, so that they can maintain it and improve it. I plan on this being the vast majority of service modules.

• $YOUR_ACCOUNT/$SERVICE: It’s my goal for the services contained in the ex-aws org to be high quality, largely complete, and maintained by active people. There will be services where that isn’t possible yet, but that’s OK. I want the documentation in core to be easy enough to follow that anyone can create their own little wrappers around core if all they need is a specific helper function or two.

Outside of the library split up, this shouldn’t cause breaking changes for people using ExAws. They’ll need to add some more deps but once they do so, it should be fine.

ExAws is widely used within the community, so I wanted to post this here so that people are aware of the coming changes, and so that I can get some feedback on how people feel about it.

Thoughts?