4 ms·

It's awesome that they reached out to the authors of a promising community project[1] and adopted that, rather than building their own project from scratch. AWS

by bgentry 12y ago

It's awesome that they reached out to the authors of a promising community project[1] and adopted that, rather than building their own project from scratch. AWS' first-party client libraries are generally awful, but I think this one stands a chance to be very good. Also, the current situation with goamz is truly horrific. There are multiple independent forks of the original Canonical Launchpad-hosted version, each with their own subtle differences in usage, interfaces and feature support. None of them feel like idiomatic Go. It really would be unlikely for this now AWS-supported project to end up doing worse than the status quo. [1] mainly Coda Hale from Stripe, where the project originated: https://github.com/stripe/aws-go https://github.com/stripe/aws-go

jeffbarr 12y ago
> AWS' first-party client libraries are generally awful Do you have some feedback that I can pass along to the AWS SDK team?
- jbergknoff 12y ago
  The node.js library [1] is incredibly well done. It's easily the best-documented node.js library I've ever seen. [1] https://github.com/aws/aws-sdk-js https://github.com/aws/aws-sdk-js
- omarforgotpwd 12y ago
  I like the first party libraries personally, because I find them to be very full featured.
- hoodoof 12y ago
  > AWS' first-party client libraries are generally awful Not a reasonable comment.
- bgentry 12y ago
  Sure, but going from memory on this :) As far as the Ruby SDK, my opinions are mostly based on how things were 2-3 years ago, when I wrote it off entirely after inheriting several large projects that made heavy use of it. In the past, it was difficult (impossible?) to figure out how it worked by reading the code. That's highly unusual for a Ruby library. It felt like a generated library, not like Ruby. When something wasn't working as expected (which happened often), it was difficult to figure out what was going wrong and why. As a heavy AWS user, I've felt much more comfortable using Fog, even though I only really use its AWS provider. That's true even though I didn't even get to take advantage of Fog's multi-provider abstractions (basically just using it to make raw AWS API calls). Hopefully that's all in the past and I should give it another look the next time I'm doing that stuff in Ruby. Fog also gave much better control over a lot of the details that are important when doing stuff in production, like timeouts and keep-alive settings. The 2nd example that comes to mind is the AWS Flow framework for Ruby: https://github.com/aws/aws-flow-ruby https://github.com/aws/aws-flow-ruby Flow does things like create global methods ( https://github.com/aws/aws-flow-ruby/blob/master/aws-flow/lib/aws/decider.rb#L60 https://github.com/aws/aws-flow-ruby/blob/master/aws-flow/li... ) and its DSL abstraction just doesn't feel right. It tries too hard to make it feel like you're just running Ruby code, and it's tough to determine how it uses SWF under the hood. It's such a large abstraction on top of SWF that it basically means you can't write parts of your app in anything other than the Flow frameworks for Java or Ruby. But then, the other major SWF framework I've seen (https://github.com/sclasen/swf4go https://github.com/sclasen/swf4go) also locks you in. So maybe it's just a shortcoming of SWF that it's not usable without a big abstraction layered on top of it? From what others are saying, it sounds like the newer stuff is in much better shape. That's very encouraging! Regardless, I think you've made a great decision in taking over aws-go. I have very high hopes for its future :)
  - jeffbarr 12y ago
    Thanks, this is incredibly helpful. I will pass it along to the team in the next 45 seconds.
    - bgentry 12y ago
      How well do you know the SNS team? :) https://twitter.com/blakegentry/status/539873715446878209 https://twitter.com/blakegentry/status/539873715446878209
      - abhinavg 12y ago
        I believe you need to enable "Raw Message Delivery" in the subscription attributes for that subscription for it to deliver raw JSON content instead of wrapping your message in an envelope like that.
      - justinv 12y ago
        Jeff is the chief evangelist at AWS & all around good guy over there. I'm sure he'd be able to get in touch with any team you wanted to provide feedback on!
- andrewstuart 12y ago
  The libraries are good. The primary thing needed for ongoing success is relentless commitment to 100% coverage of the AWS feature set, with new AWS features supported when they become available, not "at some later date". Nothing worse than reading about some new (or old) AWS feature that effectively does not exist because it is not supported in the client libraries.
andrewvc 12y ago
I will say that the new AWS ruby SDK is allright. It's a bit unruby-like in some places, but it's got absolutely stellar documentation, and is very complete, which is far more than I can say for a lot of projects.
- otterley 12y ago
  Agreed. I'll take outstanding documentation over stylistic perfection any day.
zwily 12y ago
I'm only familiar with their Ruby and Node libraries, but I enjoy both of them very much.
Rapzid 12y ago
You certainly may be commenting on outdated notions. I have used the .Net and the Ruby SDK's exetensively and have been satisfied with both(other than .Net being a bit behind Java with the KMS stuff).

by bgentry 12y ago

jeffbarr 12y ago

> AWS' first-party client libraries are generally awful Do you have some feedback that I can pass along to the AWS SDK team?

jbergknoff 12y ago
The node.js library [1] is incredibly well done. It's easily the best-documented node.js library I've ever seen. [1] https://github.com/aws/aws-sdk-js https://github.com/aws/aws-sdk-js
omarforgotpwd 12y ago
I like the first party libraries personally, because I find them to be very full featured.
hoodoof 12y ago
> AWS' first-party client libraries are generally awful Not a reasonable comment.
bgentry 12y ago
Sure, but going from memory on this :) As far as the Ruby SDK, my opinions are mostly based on how things were 2-3 years ago, when I wrote it off entirely after inheriting several large projects that made heavy use of it. In the past, it was difficult (impossible?) to figure out how it worked by reading the code. That's highly unusual for a Ruby library. It felt like a generated library, not like Ruby. When something wasn't working as expected (which happened often), it was difficult to figure out what was going wrong and why. As a heavy AWS user, I've felt much more comfortable using Fog, even though I only really use its AWS provider. That's true even though I didn't even get to take advantage of Fog's multi-provider abstractions (basically just using it to make raw AWS API calls). Hopefully that's all in the past and I should give it another look the next time I'm doing that stuff in Ruby. Fog also gave much better control over a lot of the details that are important when doing stuff in production, like timeouts and keep-alive settings. The 2nd example that comes to mind is the AWS Flow framework for Ruby: https://github.com/aws/aws-flow-ruby https://github.com/aws/aws-flow-ruby Flow does things like create global methods ( https://github.com/aws/aws-flow-ruby/blob/master/aws-flow/lib/aws/decider.rb#L60 https://github.com/aws/aws-flow-ruby/blob/master/aws-flow/li... ) and its DSL abstraction just doesn't feel right. It tries too hard to make it feel like you're just running Ruby code, and it's tough to determine how it uses SWF under the hood. It's such a large abstraction on top of SWF that it basically means you can't write parts of your app in anything other than the Flow frameworks for Java or Ruby. But then, the other major SWF framework I've seen (https://github.com/sclasen/swf4go https://github.com/sclasen/swf4go) also locks you in. So maybe it's just a shortcoming of SWF that it's not usable without a big abstraction layered on top of it? From what others are saying, it sounds like the newer stuff is in much better shape. That's very encouraging! Regardless, I think you've made a great decision in taking over aws-go. I have very high hopes for its future :)
- jeffbarr 12y ago
  Thanks, this is incredibly helpful. I will pass it along to the team in the next 45 seconds.
  - bgentry 12y ago
    How well do you know the SNS team? :) https://twitter.com/blakegentry/status/539873715446878209 https://twitter.com/blakegentry/status/539873715446878209
    - abhinavg 12y ago
      I believe you need to enable "Raw Message Delivery" in the subscription attributes for that subscription for it to deliver raw JSON content instead of wrapping your message in an envelope like that.
    - justinv 12y ago
      Jeff is the chief evangelist at AWS & all around good guy over there. I'm sure he'd be able to get in touch with any team you wanted to provide feedback on!
andrewstuart 12y ago
The libraries are good. The primary thing needed for ongoing success is relentless commitment to 100% coverage of the AWS feature set, with new AWS features supported when they become available, not "at some later date". Nothing worse than reading about some new (or old) AWS feature that effectively does not exist because it is not supported in the client libraries.

andrewvc 12y ago

I will say that the new AWS ruby SDK is allright. It's a bit unruby-like in some places, but it's got absolutely stellar documentation, and is very complete, which is far more than I can say for a lot of projects.

otterley 12y ago
Agreed. I'll take outstanding documentation over stylistic perfection any day.

zwily 12y ago

I'm only familiar with their Ruby and Node libraries, but I enjoy both of them very much.

Rapzid 12y ago

You certainly may be commenting on outdated notions. I have used the .Net and the Ruby SDK's exetensively and have been satisfied with both(other than .Net being a bit behind Java with the KMS stuff).