search

nervous-systems / eulalie

Asynchronous AWS client for Clojure & Clojurescript/Node
The Unlicense
86 stars 10 forks source link

Support reading creds from AWS CLI config #15

Open moea opened 9 years ago

moea commented 9 years ago

e.g. https://gist.github.com/mattdeboard/b1e82bd022157ab6c365

prachetasp commented 7 years ago

@moea That link is dead - any chance you still have it? I might take a shot at this

zrzka commented 7 years ago

Just curious, for what use case is this needed?

prachetasp commented 7 years ago

Mostly for local usage

moea commented 7 years ago

@prachetasp I don't, I'm not even sure what I was linking to. In general the source around this class may be helpful - not in terms of determining the implementation, just to get an idea of how the official SDK is handling it.

@zrzka In general I think being able to read credentials from as many sources as the official SDK is useful - I'm coming to the end of a large branch which reworks a lot of eulalie - using promises instead of channels, and breaking it up into separate projects with specs for the service maps - one of the changes is supporting implied credentials - i.e. issuing requests which don't explicitly have attached creds. Since falling back to instance credentials is a pain (it's hard to figure out if you're on EC2), having as many local sources as possible makes sense there, I think.

As a side note, I'm not sure what I'm going to do with the branch - have it be a separate, successor project to this, or just bump the major version but significantly change the API - because I don't know if the promise/spec/tidiness stuff is going to be as exciting to people who aren't me.

prachetasp commented 7 years ago

Out of curiosity, which branch is your current refactor branch?

If you are significantly changing the API I support creating a different project. Don't know if you got a chance to see this: https://www.youtube.com/watch?v=oyLBGkS5ICk but I think it makes a strong case for separating breaking changes into distinct projects rather than glossing over them with a major version bump.

Two things I wanted to tackle with regards to eulalie were creds fallback and adding S3 support. I am not sure whether an S3 library is better created as a separate project or not. You seem to make the case for external libraries, however, still maintain significant functionality (Cognito, SES, etc.) within eulalie itself. Are you leaning more towards either of these routes for the future?

Finally, wanted to say I'm very impressed with these libraries and appreciate all the hard work you've put into them. Keep up the good work!

moea commented 7 years ago

@prachetasp Thanks for the thoughtful response.

wip/modules is the branch - it contains eulalie-core and eulalie-services projects (w/ Dynamo and Cognito only, so far). I think i'm going to break the individual services into separate projects within the same repository (eulalie-dynamo, etc.). In addition to promises, clojure.spec, generative testing, etc. the projects now also run in a browser environment, which is great.

I was fortunate enough to see the keynote in person, and am definitely leaning towards just not having a unified eulalie artifact post-merge - projects can just depend on individual services, which is an option offered by the JVM AWS SDK - that'll get me off the hook for having to think of a new name for the project overall, without having any conflicts with the existing artifact.

As far as external libraries, the current approach is to have a complete, high-level, opinionated service implementation within eulalie, using third-party libraries only for utility functionality. I think it was a mistake to concentrate so much functionality inside eulalie itself, and wip/modules only provides services which do request construction, retry, key hyphenation, etc. - no type mapping, aliases, etc. - so division of responsibilities is much more obvious.

S3 would be great. One thing likely to be more of an issue w/ S3, as opposed to, say, Dynamo, is that currently eulalie only supports immediate request/response bodies (strings or byte arrays) - i.e. the entire body must reside in memory at once. Figuring out how to present a stream abstraction unified across the browser, JVM and node might be a little work, but my hope is that it can be decoupled from the S3 implementation - i.e. there's initially a service impl which just deals with strings, and the stream stuff comes into play once eulalie supports it.