Really happy to see these projects for automatically generated code for based on service descriptions. Minimal code to maintain and near instant updates for service providers. I was thrilled to see Amazonka (https://github.com/brendanhay/amazonka) a little while back. Great to see this done in Go as well!
Excuse my ignorance, but isn't this essentially a tight(er) coupling between the client and the server, something we have been trying to avoid with REST and, especially, HATEOAS? What happened to API “discoverability”? As I understood HATEOAS, the point was that the client just had to know how to work with particular data types (that's the point of an API, really), but was not expected to know or construct URLs beforehand, thus loosening the coupling to the server. Did I get it wrong? Did that path prove to be unrealistic?
That was not the path taken by Amazon as they made their nearly 40 different APIs. Engineers from there could certainly speak to the circumstances behind their choices.
As for aws-go, I had some APIs I needed to use and a machine-readable description of those APIs. The choice was pretty clear.
Feel like I'm in college and missed a class lecture - what's the standard for JSON API descriptions and where can I learn more so that I can upgrade my APIs to have a usable JSON description?
Follow-up: Looks like JSON Schema is emerging as the standard, in part thanks to Swagger and Google adopting it for their APIs. References to Amazon and Heroku doing so as well (not exhaustive list, just what I've found while searching).
Not sure if there's really a _standard_, but there are examples of projects[1] and generators[2] that encourage best practices. Presumably if you can document your API as JSON, it should be reasonably well-formed.
All of the Google API client libraries are automatically generated. There's a discovery document that's published for each API to allow for this: https://developers.google.com/discovery/
There is a similar Perl implementation that we use at my company (Semantics3), which uses auto generated code from the botocore - https://github.com/pplu/aws-sdk-perl
To be fair, it took them ages to start getting serious about Python. It's still not what I'd call a first-class citizen, in that boto (even with paid AWS employees on it) lacks support for things like their ElastiCache discovery protocol (last I checked earlier in the year).
Source: I heavily contributed to boto in years past. It has progressed by leaps and bounds since then, but I still don't see it mentioned in the AWS blog posts when Ruby/Java/PHP get new shinies.
Well, AWS CLI is built on botocore. I've used boto sinne 2012 and never got the feeling it's a second class citizen. Mitch's leaving Amazon didn't slow things down. Nowadays when new services are released there is usually a new version of boto available immediately.
After spending so much effort trying to get boto 3 to work with python 3 I completely gave up and re-wrote all my scripts in python 2. August isn't that far away.
there are languages inside of Amazon that are first class citizens (java & ruby mostly, node.js more now). Go is too new, moving too fast, and hasn't seen the same kind of adoption yet to warrant an SDK.(despite what the folks here might think..)
This sort of argument is very odd. Amazon can't justify putting the resources into building a golang SDK for AWS but it appears that Stripe can. Perhaps even more strangely, someone who works at Stripe can justify doing it on their spare time, but Amazon what hasn't got the money to justify it?
Companies that provide programmable systems should be the first to provide SDK's, even for technologies not yet widely adopted. That goes for any company that provides something programmable.
Amazon appears to have no trouble at all justifying the massive development effort required for every new back end web service they build, but front end programming API access just isn't valued as much.
Amazon appears to have no trouble at all justifying the massive development effort required for every new back end web service they build, but front end programming API access just isn't valued as much.
Honestly, is that really a surprise at all?
REST web services work well. Most languages have frameworks with excellent support for them.
Historically, the community has provided wrappers for popular APIs pretty quickly.
In the specific case of Go, it's still in early adopter territory. That means they are unlikely to have a problem using the raw APIs.
> Amazon appears to have no trouble at all justifying the massive development effort required for every new back end web service they build, but front end programming API access just isn't valued as much.
Their back end services make them money. Creating a Go API does not.
Makes it hard to justify investing development resources.
I guess they also have a lot of software running that they rely on and is written in C or C++. And still, there is no SDK - there is also no (Node)JS SDK. Using Docker does not force you to support golang in any way.
For AWS, not so long time ago NO, right now it is a YES. If you look at boto, it still doesn't have built-in client side encryption, while Java has. It is trivial to implement your own with Python, however it does tell there is difference here.
For internal projects, situation is even worse and many of them are community-maintained.
Why is it so many of these submission titles tend to include "in Go" at the end?
There are many, many submissions of things written in many languages and they don't generally append "in Scala", "in JavaScript" or "in Julia", etc., unless it's a post specifically about the language features or experience of writing the given software in that language.
When it's a tool such as this, is there some reason why it matters to a user if an app was written in Go specifically? Are Go users just particularly zealous? Honest curiosity here.
Because otherwise it makes the object of the title impossible to understand. There's already plenty of libraries of this kind of other languages. Not for Go.
