I recently received this message from a reader:
As it turns out, this isn’t a single question, but this reader has asked multiple open-ended questions in one comment.
So let me start with the first question.
The Firebase ecosystem consists of multiple services. While Firebase may have started as a simple data store, it now contains a lot more things including:
- crash reporting for mobile apps
- Android test lab
Take a look at this screenshot from their homepage: (I think some of these services overlap)
Firebase Cloud Storage and Cloud Functions
Not everything in the above screenshot is of interest to us. We use two services from the list above (that I am aware of) in Dialogflow webhooks: cloud storage and cloud functions.
Firebase Cloud storage provides data storage on Google’s cloud, as you might expect. It is not a typical relational database with rows and columns. Rather it is a document database, where the data is stored in JSON like hierarchical format.
Firebase Cloud Functions is an offering which is a part of the Firebase ecosystem, and as the blurb says, you can use it to
“Run mobile backend code without managing servers”
In reality, you can run not just mobile, but any backend code without managing servers. When you get a chance, you should definitely read up on cloud functions and especially how they differ from deploying your server side code in the usual way.
How Firebase is used by Dialogflow
You can write your webhook code and deploy it to Firebase Cloud Functions. Since Google owns the end to end infrastructure when you deploy your webhook code using Firebase Cloud Functions, they added an inline webhook editor right into Dialogflow’s console.
(They could have done the same thing by allowing you to deploy your webhooks to the Google App Engine instead. But that means you will have an extra step of provisioning resources for your code, separate from your Dialogflow app development. If you understand this difference, you should also be able to see where Cloud Functions really shine.)
The firebase cloud function code then uses the Firebase cloud storage for saving/retrieving data.
Firebase webhook vs Heroku webhook
Now, with all the introduction complete, we can answer the initial question. Is it a good idea to start with using Firebase (i.e. the inline webhook editor)?
As of Feb 2018, my answer is No.
Here is why:
Heroku is easy
The 1-click deploy from GitHub to Heroku is very easy. The entire process for deploying webhook code is quite streamlined, and it takes me only one article to explain the whole thing.
Google’s services are updated really fast. In fact, too fast for their documentation team to catch up. You often see folks from Google’s team answer a question on StackOverflow pointing out something which is missing in the documentation page. While it is wonderful that they help out like this, it is not super helpful for the devs who work on Google stuff because many of them are more likely to head to the docs first.
Firebase Cloud Functions has a lot more moving parts – here is a checklist based on my multi-step tutorial.
- enable cloud firestore
- initialize Firebase Cloud SDK for cloud functions
- write and deploy the code
- trigger the data update from Dialogflow
If you read the post about Firebase Cloud SDK, you will note that it has multiple sub-steps, some of which require that the user spend time understanding what is happening under the hood. I wrote the tutorial, and I am still not 100% certain!
In addition, you cannot write your code inside the inline webhook editor forever. It is not a true IDE. So you will then also need to figure out source control, debugging and deployment for your cloud functions code. (Yes, you need to do this no matter which way you do the webhook code. I am pointing this out because people shouldn’t think they can just write all their code inside the Dialogflow console forever, simply because they are using the inline webhook editor)
Python vs NodeJS
Another issue is with the actual programming language used in these two tutorials – the Heroku tutorial uses Python, while the inline webhook editor uses NodeJS. My opinion is that Python is more beginner friendly, and considering that many people seem to be attracted to Dialogflow because of its visual interface, those folks are more likely to pick up Python code than NodeJS code. (Note: but I think you need to have a programmer on the team if you want to make the most out of Dialogflow)
I recommend starting with the Heroku tutorial first. But you will run into a limitation there: using databases is not easy in Heroku. But after you deploy a webhook to Heroku, and handle a few Dialogflow actions correctly, you will get a good understanding of how webhooks work. You can always simulate the database behavior right inside your code if you are creating a prototype app.
At that point, you have the following options:
- learn to use databases and stick with Heroku itself
- use Python for the webhook code, but deploy the code on the Google Cloud (or any other cloud of your choice)
- use Google Cloud Functions to write your webhook code
When you follow this suggestion, you would have understood most of the tradeoffs by the time you choose where to host your webhook code.
Have a question?
Ask here. (Note: if the question is too broad for a single article or doesn’t fit the scope of this blog, I may not be able to answer it. In that case, I will let you know the reason via email).