Creating an Alexa skill is a lot like cooking a delicious meal. There are several ingredients, and recipes are based on your taste and preferences. The Alexa Skill-Building Cookbook on GitHub gives you the ingredients and recipes you need to build engaging Alexa skills, using short code samples and guidance for adding features to your skill. With each installment of the Alexa skill recipe series, we’ll introduce you to a new recipe that can help you improve your skill design and customer engagement. You’re the chef. Now, let’s get cooking.
When it comes to Alexa skill building, designing and developing a customer experience that is perceived as quick, speedy, and efficient is important. In a previous post on responsiveness, we talked about improving perceived latency of the customer experience using the Progressive Response API. We shared how you can add content as a sort of auditory loading indicator while Alexa is computing a complex outcome. It’s a lot like asking a person you’re conversing with to pause, while you divert your attention to complete a task. Setting the expectation that a customer will have to wait momentarily is a good idea since it’s a natural, fundamental part of dialog. It also confirms that Alexa has understood the request and is in the process of responding to it.
Although, setting the expectation that a customer may have to wait a moment is good – wouldn’t it be great if we could actually improve the underlying responsiveness of an HTTP request from an Alexa skill? There’s a simple strategy we can employ to speed up how content is fetched from APIs. And while it’s a performance engineering practice (which is a field in and of itself), it's a quick, low-cost, and an easy-to-deploy solution. The practice is to enable a caching mechanism. Caches store data so that future requests for the same data can be served faster. In most cases, this will be the result of an earlier computation.
Amazon API Gateway is a fully managed AWS service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. Whether or not we own the REST service that we're fetching, we can implement a robust caching mechanism with Amazon API Gateway that should help us reduce the latency of subsequent HTTP requests.
API Gateway can be setup as a passthrough API server. This means that any third-party APIs that you're trying to connect through your Lambda function will simply pass through API Gateway. It is important to note that caching is charged by the hour and is not eligible for the AWS free tier. You should also check the license of your third-party API to make sure that your cache is within the terms of use.
Yes, this introduces an extra hop between your customer and their data, though it will be worth it! API Gateway will be configured in such a way that any subsequent requests for the same data (or the same query) from any customer will hit your API Gateway cache. This means the time taken in the journey to do a full round trip to the third-party API endpoint will be greatly reduced.
What's great is that we only have to go through some configuration. First, we'll be setting up the passthrough API by building a new API with HTTP proxy integration with a third-party endpoint through a proxy resource.
Now your Passthrough API is live! Instead of going directly to your third-party URL, you can simply pass your query parameters through your own API.
And now all we have to do is enable caching! When enabling caching, you must choose a cache capacity. In general, a larger capacity gives a better performance, but also costs more.
In the API Gateway console, you configure caching in the Settings tab of a named Stage Editor.
To configure API caching for a given stage:
If you would like to verify if caching is functioning as expected, you have a few general options:
API Gateway also has plenty of features that make it fast and scalable (i.e. available in multiple zones, has redundancy mechanisms, staged environments for testing, etc.). Take a look at the full developer guide to learn more.
There are also trade-offs to consider with this approach. Instrumenting a cache means that your data will not always be fresh. Most caching strategies are based on a TTL (time-to-live) mechanism. This means that the data inside your cache goes stale after a set time period. For example, if you have a TTL set to 24 hours, your cache will keep data for a full day before flushing it and accepting new data. That's why caches don't always work for edge cases that require absolute real-time data. But for most practical purposes, a brief (even a few minutes) TTL caching mechanism can do wonders to backend/API load as well as the customer experience.
As I mentioned, you can use the caching mechanism and the Progressive Response API recipes together or individually to improve the responsiveness of your Alexa skill. Start by analyzing your customer's needs and the purpose of your skill to arrive at the perfect balance.
For more recipes, visit the Alexa Skill-Building Cookbook on GitHub.
You can make money through Alexa skills using in-skill purchasing or Amazon Pay for Alexa Skills. You can also make money for eligible skills that drive some of the highest customer engagement with Alexa Developer Rewards. Download our guide to learn which product best meets your needs.
Bring your big idea to life with Alexa and earn perks through our tiered rewards system. Publish a skill in May and receive an Alexa backpack. If 1,000 customers use your skill in its first 30 days in the Alexa Skills Store, you can also earn a free Echo Plus. Learn more about our promotion and start building today.