How to build a server-less application which handles authentication, saves details to DynamoDB, and communicates via Amazon's Alexa-enabled products.
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:
- Overview (this article)
- More detail on configuring the Alexa Skill
- 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:
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.