← All Articles

Create a custom Alexa Skill with AWS Lambda - Part 1 (Overview)

One of my birthday presents this year was an Amazon Echo, quite a neat voice-activated device that sits on our kitchen counter.

Unfortunately there were no skills available for something I wanted to do, so (naturally) I spent a couple of afternoons creating a custom Alexa Skill (using the Skills Kit).

These are my notes in 3 parts:

  1. Overview (this article)
  2. More detail on configuring the Alexa Skill
  3. Creating Lambda functions (coming soon)

I had to setup an Oauth authentication flow, save a few user details to DynamoDB, and communicate between the 3rd party (MyFitnessPal) and the user via Alexa's voice commands. Here's how I did it:

![Alexa skill using Lambda design](//images.ctfassets.net/4kz0eniowskz/4sBRr9fvVzt9wMK4gHNfRw/bfaf5a9e6e28457e75c748ff12719de6/lambda-alexa-design.png)

This functions as a server-less application which adds food items to MyFitnessPal.

I wrote the Lambda functions in Python, although that code isn't actually that interesting so I won't go into it in much detail. I'd rather note down the various gotchas and configuration issues from setting up this server-less app. Let's break this down a little.

Step 1: User speaks to Alexa

In order for Alexa to understand your commands, it essentially namespaces all commands within a "Skill" which you must create and configure. This is done through the Alexa Developer Console. This is where you configure settings like:

  • your invocation name, eg Alexa, open `my-skill-name`.
  • your interaction model, eg when the user says "Do `this` to `that`", then handle this with a particular "intent"
  • which Lambda function handles the backend for your skill
  • URL to redirect to for authorization and account linking (in my case this is another Lambda function)

I will go into more detail about configuring the skill in a future article.

Step 2: Main Lambda function

Amazon has positioned Lambda as "serverless compute" - meaning that the application is not "always on" like a traditional server, but is "spun up" only when a request is directed at it. There are several languages supported on Lambda, and I chose to write my lambda function in Python.

Lambda functions need to be configured with code, access management roles, and triggers, and there are a few differences if you are used to a traditional server. I go into this in more detail in another article too.

Step 3: API Gateway

Lambda functions are not publicly accessible by default. In order to send GET and POST requests to a Lambda function (like when I wanted to exchange oauth tokens) requires setting up an API Gateway. This lets you direct a particular URI to a particular lambda function.

Step 4: Saving / reading from DynamoDB

I setup another lambda function behind the API Gateway, and this handles saving and reading from DynamoDB. This is Amazon's NoSQL service, which I used to store credentials for use with the 3rd party app.

So we've covered an overview of how to setup a new Alexa Skill to communicate with any 3rd-party app, using OAuth and lambda functions. Read on for how to configure the Alexa Skill in more detail.

Made with JoyBird