Do I have to use API.AI to create an action for Google Home? - actions-on-google

I have some experience building chat and voice agents for other platforms, but I’m not using API.AI to understand natural language and parse intents. Do I have to replace my existing solution with API.AI?

Not at all. The advantages of using API.AI in creating a Conversation Action include Natural Language Understanding and grammar expansion, form filling, intent matching, and more.
That said, the Actions on Google platform includes a CLI, client library, and Web Simulator, all of which can be used to develop an Action entirely independent of API.AI. To do this you’ll need to build your own Action Package, which describes your Action and expected user grammars, and an endpoint to serve Assistant’s requests and provide responses to your users queries. The CLI can be used to deploy your Action Package directly to Google, and you can host your endpoint on any hosting service you wish. Google recommends App Engine on Google Cloud Platform.

I found this explanation from the official page most helpful.
API.AI
Use this option for most use cases. Understanding and parsing natural, human language is a very hard task, and API.AI does all that for you. API.AI also wraps the functionality of the Actions SDK into an easy-to-use web IDE that has conveniences such as generating and deploys action packages for you.
It also lets you build conversational experiences once and deploy to many other platforms other than Actions on Google.
ACTIONS SDK
Use this option if you have simple actions that have very short conversations with limited user input variability. These type of actions typically don't require robust language understanding and typically accomplish one quick use case.
In addition, if you already have an NLU that you want to use and just want to receive raw text and pass it to your own NLU, you will also need to use the Actions SDK.
Finally, the Actions SDK doesn't provide modern conveniences of an IDE, so you have to manually create action packages with a text editor and deploy them to your Google Developer project with a command-line utility.

Google is pushing aggressively everybody to API.AI. The only SDK they have (Node.js) no longer supports expected events for instance. Of course, you don't need to rely on their SDK (you can talk to the API directly) but they may change the API too. So proceed with caution.

Related

Programatically create Conversational Action on Google via an API

Google has recently released the Conversational Actions skill creation kit. From my understanding, it differs from the previous Actions on Google set that was available and, indeed, on the integrations part of Dialogflow, the AoG integration is now considered legacy, and separate from Conversational Actions.
Is it possible to create a new Google Conversational Action via an API? All the documentation ends up mentioning the Actions API at some point or another. However, clicking on the "Documentation" tab on the API page does literally nothing.
On the Conversational Actions reference page, there are numerous manifest definitions for various things, such as Entities, Actions, Intents, Scenes... Is there an API somewhere that would allow for programmatic creation/update of actions?
If so, what is the preferred method of authenticating with said API? oAuth, some sort of a token?
I have asked a similar question before about AoG, and the answer was "no". Has anything changed?
IMPORTANT: gactions CLI is off the table. I know it's available, its usage is less than ideal.
The short answer is no - the Actions API is not publicly documented or available, although you need to grant your Google Cloud project access to it if you want to use the gactions CLI.
Clearly there is an API somewhere, after all, gactions needs to be permitted to it, as you note. But they haven't made it available. (At least not yet.)
Judging just by the gactions command, it would be able to do most, but not all, of everything needed for the "programmatic creation/update of actions". While it would be able to update actions, it can't create them - right now that needs to be done through the web console. Although you can create a project using the gcloud command, there does not seem to be any way to "promote" it to an Actions project - trying to use gactions at this point just gives an error that says you need to create it in the console.

Dynamically Change API Environments Google Rollout Track

I'm developing an Ionic(3 / 4)(Angular 4 - 7)-Cordova / Capacitor Cross Platform Application(s). I'm interested in switching API env based on the current rollout track in the Google Play Store. For example, once an application has been successfully tested and recommended to continue staging/production. I would like to have the API env dynamically changed (e.g., using a different URI domain to connect to REST API ) dependent on the Google Play Store Track.
I'm aware that I can use Google Developer Play Store API to identify / list versions and available tracks yet, I'm unaware if there's already an implementation or solution. I'm perfectly willing to design a solution though, I figure I find out if it's been done already rather than reinvent the wheel.
I'm hoping to implement a solution either to the REST API BACKEND or in the ionic framework layer rather than an integration at the native layer for scalability per-project. The purpose of doing this would enable CI rather than rebuilding the project and change the API URI domain for every environment. Any assistance in this matter would be greatly appreciated.
So, if anyone's interested. The approach highlighted above is possible, couldn't get an answer so I just created something. Using Google Play Developer API. The process flow is as follows:
[]
For now it's a working prototype perhaps its not very efficient; I suppose it can be improved if the request was issued from a single server, or microservice. Though, I wanted to make the code recyclable and it's isolated from both the mobile application & Node Server.
If you are interested in learning more or would like to work on project. Please feel free to contact me.

How to deploy and maintain multiple chatbots agents

This post follow this one where I explain one of my problems. Currently, I have to found a way to publish and maintain a high number of agents. I am not limited to Dialogflow.
I need some integrations like the google assistant (text and vocal), facebook messenger, telegram and if possible others like Slack, Twitter, Twillio, Alexa...
Okay, so I have already produced some agents with Dialogflow to understand the technology. I also read some pages of the actions-on-google documentation and I did'nt found anything on this subject. So basically I have to implement this:
Deploy around X agents through differents integrations instanciations. I mean I really need X facebook contacts, X google assistant apps, etc.
Maintain one code-base but have the ability to add localized-features like the name of the chatbot, currency or just block some intents (for Dialogflow example but in a more generic way, dialogs triggers).
It is just possible ? I am thinking about a web UI that can handle some facilities like the deployment, the monitoring and the maintenance. I am wondering if it's not overkill and if a more easier solution than mine exists already.
It isn't currently possible to create agents automatically, although Dialogflow's V2 API provides a mechanism to update agents via JSON once they have been created; see the restore and import endpoints.

Where to host Smartsheets API code

I am interested in learning to use the Smartsheets API. In the past I created workflows in Google Apps Script, which has a built in IDE that houses the script. Does Smartsheets have something similar? If not, where is a common place to keep your code and have it react to webhooks/events?
Regards,
Shawn
The API is just a way to communicate between your application and Smartsheet - there is no hosting for your executable code. Smartsheet provides a number of SDKs to help make the calls easier to perform, but in theory you could use any language to make the REST commands. So, pretty much any service that allows executable code would work, such as Amazon AWS, Google Cloud, Microsoft Azure, or others. Here's a brief comparison of services.
You can start developing on your own computer before you worry about cloud deployment. See the getting started guide and samples here: https://github.com/smartsheet-platform/getting-started
If you really need to respond to webhooks, your code will have to run somewhere that accepts incoming HTTP calls from the Internet without being blocked by a firewall. This could be in your data center, any of cloud services, or via a tunnel such as https://ngrok.com/

How to integrate a comment system in an ios app?

Lets say my web server app is in drupal or wordpress, or even code igniter, how would one get about integrating a comment system? TSpecifically what I am trying to find out is if anyone was able to find a successful approach that would save some time as opposed to me going down the road of tying myself to a specific CMS content system.
Just throwing in some considerations here (by no means complete):
Are users also accessing your content (and its comment system) via the website?
If so, you'll want to have a comment interface that is available on the website too, and the easiest choice may be to use the comment system natively supplied by your CMS / through plugins.
If on the other hand your users will only be using the iOS app(s) for commenting (via a native interface) or you'll be heavily customizing the website anyway, using a comment system independent from your CMS might be an option.
How will the content be accessed from the app?
Via a simple web view? Or will the app download via an API provided by your CMS and display it in a native UI? If you are using an API provided by your CMS, you will have the same issue with your content as with your comments when moving CMSes.
You could add an intermediate layer that abstracts from the specific CMS API.
Or if you don't really plan on moving CMSes but want to prepare for that event nevertheless, you could simply implement a no-frills "version check" to ask the server for the CMS kind / version it is using, and if it doesn't match what your app expects, ask the users to update. This isn't the prettiest user experience, but it might be sufficient depending on what you're actually planning.