This is a post about where to host your webhook. However, this is not a post about cloud service providers. I am not going to talk about which one is better – Google Cloud or Heroku or AWS or Azure.
Rather, I am going to ask you to consider the option of placing your webhook outside of your Dialogflow process.
How the webhook works
Generally speaking, the webhook works like this:
- End user sends a message to your Dialogflow agent via
- a messaging channel such as Twitter or Slack
- through Dialogflow’s test console
- an API call
- Your agent maps the message to an intent
- The agent sends some JSON to the webhook
- The webhook performs business logic after extracting relevant information from the JSON
- The webhook generates a JSON object which contains the results of the business logic
- The webhook’s JSON is sent back to the Dialogflow agent (which is running on Dialogflow’s server)
- Inside the JSON, there is a field which the Dialogflow agent looks for (displayText) and either
- displays the text in the field if the end user is interacting from one of the messaging channels such as Twitter or Slack
- displays the text in addition to showing the JSON (via the Show JSON button) if using the Dialogflow’s test console
- returns (more correctly forwards) the JSON to the caller if it was an API call
The 5 second limitation
Dialogflow imposes a 5 second limitation on your webhook to respond. If it doesn’t, it is treated as a timeout. There are many who feel that if you cannot respond in 5 seconds, you might be doing something wrong. That is a valid point, but unfortunately in the real world you are going to encounter scenarios where the 5 seconds are not going to be sufficient.
When you place your chatbot on your website (as opposed to using a channel such as Slack or Twitter), you have an interesting choice to consider.
Here is an alternate approach to doing everything the webhook can do.
- End user interacts with your website chatbot (i.e. sends it a message)
- From your website, you call the Dialogflow agent via REST API call
- Your agent maps the message to an intent
- The agent sends the JSON back to your website process
- The website process will perform the webhook business logic by calling another service
- After the service performing the business logic returns, the website process will return the response to your end user
Notice that in this case, you have worked your way around the 5 second limitation imposed by Dialogflow.
This raises many questions.
Will this approach mess up the state of the system (i.e. contexts)?
If you use the proper method of setting a unique session ID when interacting with your REST API, it shouldn’t cause any problems. The context is saved on Dialogflow’s servers, and is sessionID specific. When the next request goes to Dialogflow, as long as the correct sessionID is used, the system state will be maintained as expected.
What happens if the webhook updates the context via contextOut?
You can replicate this behavior by setting that same context when sending the next query from the user. Alternately, you can also explicitly set the context by calling the REST API.
What happens if the webhook uses a followupEvent?
You can simply trigger the event via REST API call from your website process. You will get the same overall effect.
Aren’t you using Dialogflow as a thin NLP layer in that case?
Yes, but that is true even if you use the traditional webhook.
Wait, can this still be called a webhook?
Hmm.. I don’t know. But does it really matter? 🙂
There are probably some issues I haven’t considered, and would also love to know your thoughts in the comments.
Lastly, I am planning to use this approach in one of the test chatbots I am building for my own site. I will keep you posted on the results. Instead of considering this as a solid recommendation, think of this post as a proposal for an alternative option (especially if the 5 second timeout rule is too hard for you to work with).
This website contains affiliate links. See the disclosure page for more details.
"The magic key I needed as a non-programmer" The custom payload generator was the magic key I needed (as a non-programmer) to build a good demo with rich responses in DialogFlow Messenger. I've only used it for 30 minutes and am thrilled. I've spent hours trying to figure out some of the intricacies of DialogFlow on my own. Over and over, I kept coming back to Aravind's tutorials available on-line. I trust the other functionalities I learn to use in the app will save me additional time and heartburn. - Kathleen R Cofounder, gathrHealth