Amazon Web Services and Go: Feel the Love

By Trey Tacon

My co-workers teased me a bit when they found out I was blogging about Go once again. I’ve been singing its praises for a few years now because I personally believe it is the programming language of the future. But I’m not alone. Amazon Web Services is feeling the love and just announced that it will be among the first to provide an officially supported software development kit (SDK) for Go.

More APIs, Please
More and more companies have been offering public APIs in the past few years. I believe this is largely a consequence of increasing interest in microservices and the flexibility and agility they provide to developers. Because microservices expose simple interfaces (APIs), it’s easy to attach a slightly more controlled interface on top. Viola! …now you’ve got a publicly available API.

Most APIs are REST APIs (over HTTP), which means we’ve made an HTTP request to a specific URL to invoke a specific action or to retrieve a specific entity. Instead of perpetually rewriting the necessary code to make these HTTP requests, developers often write “clients” (also often called SDKs) in the language of their choice which wraps this REST behavior.

More often than not, however, companies will provide a language specific SDK for only one or two languages. This means client libraries for all other languages have to be created and maintained by that language’s community.

It Takes a Village
We tend to judge the popularity of a language by how easy it is to find a client library in that language for a given API. For example, many sites offer Ruby client libraries – including APIs offered by GitHub, Google, Travis-CI — the list goes on and on.

When I started writing in Go, there were (almost) no “officially supported” client libraries in it.

Luckily, Go is a community-driven language, and we Gophers rejoice in our “build it and they will come” mantra. And just as I’d hoped, we built libraries and those who loved Go came to use them. In my opinion this is one of the reasons that almost all Go clients for APIs are community-developed and community-maintained.

So imagine my surprise a couple weeks ago when Amazon Web Services made its announcement to support Go with its own official SDK. (happy dance)

Stripe meets Go meets AWS
Since Go 1.4, we’ve had access to a tool in our toolchain called ‘go generate’. By running ‘go generate’ you can bypass the need to separately build yacc grammars, protobufs, etc., either on your own or through individual Makefile recipes. Awesome, right?

But the Stripe-created AWS Go client took that to a new level. Instead of writing the Go client code, Stripe generated it from a JSON definition of all of AWS’ services and endpoints. Beautiful. This saves AWS from hunting through code to make the changes in the Go client whenever a new feature is added to one of its services. Instead, it’ll just update the JSON definition and regenerate everything. (applause)

While this will make fixing certain types of bugs more difficult, it will mean fewer bugs overall and that the Go client will never be out of date. Never!

With that said, I’d like to welcome everyone to the future and to thank AWS for being among the first to embrace it.

One Reply to “Amazon Web Services and Go: Feel the Love”

  1. I think Great talk. I’m so glad you mentioned the imraptonce of naming. In fact it shows up twice.Just the other day I was asking programming friends for help with naming. I wanted to check for a win on the diagonals of a tic-tac-toe board. And I wanted a name better than IsTopLeftBottomRightDiagonalAWin. Often when I ask for naming help I’m met with Just use that name and move on. After hearing that enough I began questioning if I was wasting my time. It’s good to hear that naming IS coding.

Leave a Reply

Your email address will not be published. Required fields are marked *