If you didn’t know, API.AI has now changed its name to DialogFlow. So what’s changed?
When the name change was announced on the blog, they mentioned the addition of two features, namely
- Inline code editor for webhooks
- Multi-lingual agent support
So are the rest of the features backwards compatible?
I took some of the agents I have created on this site on a test drive, and they seem to be working just fine.
From what I have read and observed till now, there has been no breaking changes in the functionality.
User Interface changes
Have there been any major changes in the user interface? No, nothing unexpected, actually.
The languages tab
Since the multi-lingual agent capability has been added, there is now a languages tab under Settings.
It is quite interesting to note that the multi-lingual capability has been made front and center. In fact, it is always visible because it has also been added to the left tab (although that is also the best place to put it quite frankly).
As other bot frameworks are doing a pretty good job of catching up with
API.AI (oops) DialogFlow, I had noticed a few comments on the forum mentioning that some people were eventually choosing DialogFlow for its multi-lingual capabilities. So it makes a lot of sense for the DialogFlow folks to provide the feature maximum visibility.
Inline code editor for webhook
This is definitely a very interesting feature. I will tell you why in a minute. This is what it looks like.
The first thing to note is that the inline code editor has just been placed directly inside the Fulfillment tab and doesn’t interfere with anything else.
The second thing to note is that while it is disabled by default (naturally), if you choose to enable the Inline Editor, it will immediately disable your existing webhook. DialogFlow does provide a nice little warning about this, but it is quite an important thing to note for certain.
How the inline editor affects chatbot programmers
The two things mentioned above are somewhat simple and basic changes. But here is the biggest change:
If you choose to use the Inline Editor, as many folks will almost certainly do when they get started with webhooks, you are making some default choices such as being asked to
a) use NodeJS as your server side programming language
b) put your webhook on the Google Cloud
c) use Firebase (which is a part of the Google Cloud) as your backend
So why is this such a big deal? I will let you decide for yourselves the business aspects of enabling the inline editor. (Frankly, DialogFlow is now owned by Google, and Google has every right to push its cloud features in exchange for ease of use).
As a programmer though, you need to be aware of what this is doing to your codebase.
NodeJS as the programming language
Google Cloud as the webhook host
Putting your webhook on the Google Cloud is likely a much simpler option, but even here you need to be a bit careful about things such as lock-in.
Firebase as backend data store
Finally, Firebase is not a relational database (I believe they refer to it as a document database), so this is a much more important concept to wrap your head around. For one thing, designing things such as database joins are not that straight forward with Firebase because it requires you to do a ton of data design up front. For another thing, you will not be able to easily migrate from Firebase to a relational DB later that easily.
Now, if you are creating an app for the Google Assistant, all the above choices are probably the best choices: nearly all the documentation and helper libraries are based on NodeJS, and Firebase is probably a good choice for an Assistant app.
(Update: Thankfully, it looks like you are not being forced to use Firebase for the backend, my bad. The topic is a little involved, read more here. The Firebase Cloud Functions provide a wrapper for Google Cloud Functions to make your job easier. The docs talk about enabling the free tier of Firebase, but you don’t actually have to use Firebase as your data store).
Using a tool like ngrok
If you are not aware, ngrok is an excellent tool for debugging webhooks. You can use an ngrok provided URL in the Fulfillment tab in DialogFlow, and ngrok will automatically route the request to your local development machine so you can start debugging the code! ngrok is an excellent tool, but you should be aware that such a tool will always raise some security concerns.
My question has to do with debugging the code if you were using the inline editor. I suppose right now the way to do it is to have an exact replica of the code between your dev machine and the inline code editor. (Please let me know if this is incorrect)
As the blog post says quite clearly, the name API.AI was never a great name.
- It barely hints at the use cases (Natural Language Processing, chatbots, etc).
- The name is hard to pronounce, especially during screencast presentations. DialogFlow has 4 MORE characters, but still 2 fewer syllables.
- When you want to talk about the REST API exposed by API.AI, you can’t simply say “Use API.AI’s API endpoint” because it looks quite weird. Saying “Use DialogFlow’s API endpoint” is just so much easier to read
- Their REST API endpoint was actually called “api.api.ai”. So in addition to being confusing, it was a lot of syllables for a very small phrase
- This is a little bit of a pet peeve of mine and probably doesn’t affect anyone, but GMail (as well as the Discourse forum) will automatically hyperlink API.AI even when there is no intention to link to the site. DialogFlow is so much better!
Anything else you want me to discuss?
Leave a comment below (the site uses Disqus conditional load, so it may take a minute to load)