A couple of years ago I was lucky enough to win an Echo Dot in a company hackathon. Since then I have been trying to develop Alexa Skills that interest me in my spare time. Before exploring this new field of development, I had been interested in learning and practicing a language that was new to me, Golang (or just Go). Considering Alexa skills are based on web services, one of the area where Go excels, it seemed like a great way to “have my cake and eat it too.”

It was a couple of months ago when I came across a great post by Nic Raboy on writing about writing Alexa Skills with Golang and AWS Lambda which can be found here. Most of the Skills I have developed started before Lambda had first-class support for Go so I am much more comfortable writing Skills using self-hosted web services. Using Lambda for Alexa Skills is definitely a great approach but there are some instances where using your own server might make more sense. If you are looking to reuse an existing server or rapidly prototype an idea then maybe it makes more sense to use this approach.

In this post, I will detail the steps necessary to deploy a web service that can be used to fulfill Alexa Skill requests. To make it easier to compare this approach with using Lambda, the functionality of the Skill will remain almost identical to Nic Raboy’s example. It is only the deployment process that will be changed.

It has been a few years since I last worked on and published an application, otherwise known as a Skill, for Alexa powered voice assistants. My last Skill titled, BART Control, was built out of necessity because of my commuting on the Bay Area Rapid Transit system. While I didn’t open source it, I had created the Skill with Node.js and a publicly available BART web service. Since then I had written a tutorial titled, Create an Amazon Alexa Skill Using Node.js and AWS Lambda, which also focused on Node.js.

I’m a huge fan of Golang and was pleased to see that AWS Lambda recently started to officially support it. AWS Lambda isn’t a requirement to creating Alexa Skills, but it is a huge convenience. To make things even better, Amazon recently sent me an invitation to take part in their developer offer to receive an Amazon Echo Show for publishing another Skill. The offer and Golang inspired me to develop another Skill and this time I wanted to share my process.

I was recently tasked with a project where I needed to gather data from Stack Overflow so it could be easily evaluated without having to dig around the website. Stack Exchange has many REST APIs available, some of which that don’t even need tokens or authentication, so it came down to how I wanted to consume this data.

In this tutorial, we’re going to see how to consume question and comment data from the Stack Exchange API using Golang and then export it to comma separated value (CSV) for further evaluation.

I’ve been in the web game for quite some time and have my fair share of web server software. I’ve used Microsoft’s Internet Information Services (IIS), Apache httpd, as well as NGINX, and while they all thrive in their own ways, they’ve been overkill for most of my use cases. This is where Caddy comes in, a lightweight alternative to these seasoned, but often heavy web servers.

We’re going to see how to use Caddy and learn why it is so powerful while using minimal effort on a developer operations side.

If you’ve been keeping up, you’ll remember I released a very popular tutorial titled, Getting Started with GraphQL Using Golang which was more or less a quick-start to using GraphQL in your web applications. Since then, I demonstrated an alternative way to work with related data in a tutorial titled, Maintain Data Relationships Through Resolvers with GraphQL in a Golang Application. Both articles are great, but they left out an important feature that most modern APIs must have. Most modern APIs must have a way to authorize particular users to access only certain pieces of data and not all data offered by the service.

One of the most popular ways to enforce some kind of authorization in an application is through the use of JSON web tokens (JWT). Users authenticate with a service and the service responds with a JWT to be used in every future request so that way the password is kept safe. The service can then validate the JWT to make sure it is correct and not expired.

We’re going to see how to protect particular GraphQL properties as well as entire queries using JSON web tokens and the Go programming language.

I recently wrote about getting started with GraphQL in a Golang application, where I discussed the creation of schemas, executing queries, and mutating data, even though it was all mock data. In this example there were queries for related data, but they were constructed in a very independent form.

We’re going to see how to query for related data, similar to what you’d find in a JOIN operation on a relational database, but using GraphQL and the Go programming language.

I’ve been hearing increasing amounts of buzz around GraphQL, a technology that has been around for quite a few years now. In case you’re not familiar, it is a technology for querying API data from a client-front end without having to make numerous requests or receiving unimportant data, both of which may cause negative affects on network latency.

Think of trying to query a relational database. Ideally you write a SQL query for the data you want and you do it in a single request. GraphQL tries to accomplish the same, but from an API consumption level.

We’re going to see how to implement a web application using the Go programming language, but uses GraphQL when working with the data.