Alexa Skills Kit SDK v2 : What has changed?
The Amazon Alexa developer team came up with a new version of alexa skill development kit for Alexa skill kit development. Being a developer myself who has worked on both these versions, I would like to share the context behind the difference. The main focus of the new version seems to be mainly the interface emphasizing the flexibility.
Let’s begin with what’s new in ASK SDK V2:
- The most recent feature being the beta version of display interface to create visuals for the skills.
- Error handler has been included in the same stature as request handlers, which is used to handle the skill when an error occurs in the incoming handler details.
- Interceptors have been introduced for request and response, which are useful when the skill requires multilingual characteristic. Request Interceptors are useful for adding data to request attributes while response interceptors can be used to validate data.
- The ApiClient and service clients now enable to import data from external APIs.
Now let’s look at what we’ve said goodbye to:
- No more localization, no baked-in i18next.
- No NewSessionHandlers and just one Unhandled intent for anything handled to fall on through.
- You can just call to invoke events no speech response like emitwithstate and emit is required.
- With the standard handler, you can create a table by providing name and specifying that it needs to be automatically created.
- Attributes now have three scopes: request, session and persistent. Request attributes are used for storing temporary data, session attributes go from skill to service to request until session is alive, persistent attributes are used by data store commonly DynamoDB.
- Handlers can be invoked based on value of an attribute called STATE or any other criteria, V2 doesn’t have the concept of state.
- There are two different ways to represent handlers: custom and standard skill builders. The standard skill builder allows Alexa ApiClient and DynamoDB persistence adapter while in custom it is of user-choice.
- Response builder interface has changed.
- The exported lambda handler function is different and adapts what is happening when function is called, the incoming event and context are sent to SDK to build a response.
- Lastly, handler definitions are a big change. In V1, handlers were tied to a state and used event emitter pattern by looking for event listeners for intent-state pairing. In V2 handlers are defined sequentially and each has a function to determine if it is valid for current request. Only when the function matches true for current request will the handler run. Handlers handle more in a single function and an intent can be handled by a fallback handler. There is a hierarchy among handlers which is defined by the order in which the handlers are passed to addrequest handlers. Handlers can be routed based on slot values, attributes or intents.
There has been a lot of impacts due to the focus on modularity like Connecting a skill to DynamoDB is no longer easy and simple and Processing time adds up.
The extensibility of V2 gives developers better usage of resources. With many interface changes and some functionality changes reduces size of SDK and skill handling due to significant modularity change