It seems amazonica is the defacto aws sdk wrapper, but it's a bit complicated internally imho. I cant see a way to efficiently mock it either. As far as I understood the Java SDK doesn't lend itself to testing either. There is https://github.com/bizo/aws-java-sdk-stubs which shows some nice examples how should a mock/stub sdk look like but it's not very complete and it's still just java not clj(s).

It does have an important tagline though: > Services should come with stubs

I can totally agree with it because recently I had to use the Route53 API and I had to construct some stubs myself by try and capturing the behaviour of the real API

I envision some AWS danielsz/system components - real and stub ones, maybe a separate credential provider component too - which provide an idiomatic clojure interface

Would anyone be interested helping out?

I have a super specialized implementation which only satisfies the needs of a very constrained micro project, but i can probably share that to illustrate what am i talking about

oh i hate amazonica! there's no documentation at all

@lmergen @onetom i'm wondering if you've looked at the amazonica implementation? amazonica is largely just automatically generating clojure functions around the java apis. see how set-client: https://github.com/mcohen01/amazonica/blob/master/src/amazonica/core.clj#L911 iterates through client-methods, mechanically transforming them into clojure names, and then interning a fn that looks up and determines the best-method in the api to assign to the interned fn. You could probably implement a workable stub with a small fork of amazonica, to muck with the best-method wiring, perhaps changing it to a multimethod and so then you could extensibly return stubs

yeah that's correct, i've seen that

but then the AWS java SDK has very little documentation either

and their whole API is... a bit weird, at some places

and you can easily lose a day worth of productivity because of some weird bug