Earlier this month, I wrote a post about designing a facts-based Alexa skill, that utilizes DynamoDB to serve responses. After doing so, I pondered what it would be like to build an exact same experience with Google Assistant actions. To my surprise, it was a lot harder. This may have been the curve of learning a new cloud provider, or just simply that there wasn’t as many modules to bring continuous delivery into development. However, what I did learn is Google offers an API driven design first, while utilizing machine learning to drive intents, rather than hard coded values.
Going into this project, there were two things I wanted to accomplish. The first being an easy way in which I could develop a solution in which non-developers could take the action and update the responses, all with without ever touching the actual API code. The second was to have a continuous delivery solution, that provides little headache, but pleases the former.
Scouring the web, I was astonished when I couldn’t find a serverless project, or at least one that uses simplistic design (such as YAML), to drive configuration. The deployments directory has one script whose sole purpose is to maintain configuration, encompassing a wrapper of example code provided by the SDK. With the design of the action, utilizing firebase fields to drive responses, I wanted to leverage the machine learning capabilities that Google provides. The entity names represent the metrics, and the responses come from the responses item within firebase, utilizing string replacement similar to my Alexa skill. By updating the entities.yml file, you can increase or decrease the amount of options open to a user.
Since were coming into postseason, let’s say for example you provide a metric of “dingers”, and a synonym “homeruns”. Once you update the file and run the update-entities npm script, you can then ask the assistant to tell you “how many dingers do I have”, or “how many homeruns”, and the response and total_count fields will return dynamically.
I guess that’s why the big leagues still haven’t called my number… Moreover, this may not be a complete continuous delivery effort, but its a work in progress, while still meeting the initial goal for everyday users to add entities to your metrics action.
danquack / Serverless-Google-Assistant-with-Firebase
A google assistant facts-based action designed to report metrics out of firebase
Serverless Google Assistant with Firebase
This sample google assistant dialogflow is a facts-based action designed to report metrics out of firebase. The idea is that something external would update firebase, which would then be read through google assistant.
Design
Prereqs
- Install NodeJS
- A Google Project is created
- the project should have enabled firebase, cloud functions Deployment Manager V2 API
- a service account should be created. For production, the role should be restricted but for now Owner will work.
- the credentials JSON should be placed in root of the project, as serverless will need it
Devtime dependencies
- A firebase collection must be created for facts
- The collection should contain a field of "metric" i. The field should be lowercase space separated words
- The collection should have a "total_count" and "response" attributes
- The following environment variables should be baked into your system
-
GOOGLE_APPLICATION_CREDENTIALS
- path to credentials file -
PROJECT_ID
- available in…
-
Top comments (0)