This is the first of a series of posts that talk about building an Alexa Skill using .NET.

I have been playing around with building Alexa skills for the last couple of years, but never wrote about it. The idea for this set of blog posts came as I was building one recently and found that is was very difficult to find information around this. The idea here is to have enough information to get started, rather than in-depth information of different aspects. I may also post about some problems I had, as .NET is not a supported platform from Amazon Skill Kit perspective.

Anatomy of a Skill

An Alexa Skill flow has four major entities involved in each flow:

1. The user who speaks a command to the echo or Alexa enabled device (I will use echo for simplicity in my posts, but it mean any Alexa enabled device should work).
2. The echo device, which receives the initial voice input and also plays back the final voice output.
3. The Amazon Alexa service, which receives the data from the devices, decodes it and then forwards it for processing to the backend. It also converts what it receives from the backend and sends it over to the actual echo device.
4. The actual back end services which contains the business logic for the skill itself. This can be hosted either in Amazon or outside. Amazon provides hosting in its cloud based Lambda service if you want to build these backends in Node.

So, basically when you are talking about building a skill one you are actually building of the back end service and configuring the Amazon Alexa service. A simple diagrammatic representation is a below.

The Amazon Alexa Service maps the incoming request to what are called Intents (that the developer defines) and then creates a JSON with data that you need and then sends it over to the back end services. The backend service does whatever process it is supposed to do and then returns the data back as a JSON. The JSON formats that are part of this interchange is defined by Amazon.

In this series, I am going to talk about building this Back End service using .NET, c# and then hosting it as a Azure API service. So this will be built using the default Web API MVC project type. You can deploy this to any publicly accessible endpoint and Azure just happens to be something that was easily accessible for me.

In the next post, I will talk about the different ways you can create the backend service and what you will need to do this in .NET