Home / DialogFlow / 7 things to consider before choosing your Dialogflow webhook language
DialogFlow | Webhooks

7 things to consider before choosing your Dialogflow webhook language

Wondering which language to use for your Dialogflow webhook?

In this article, I discuss some things you need to consider before choosing it.

1 NodeJS is asynchronous

While NodeJS is clearly exploding in popularity, if you are not already proficient in NodeJS, you might want to use it to build a toy project first before using it for your webhook.

For example, I got a question recently where someone was pointing out that the inline editor code “does not wait” for a request sent to a different API to return.

The reason this happens is because NodeJS is inherently asynchronous, and to make your code “wait” for a request to complete you need to learn how to use the concept of promises. So there will be a small learning curve when you start.

2 The inline editor uses NodeJS

The only language you can use in the inline editor right now is NodeJS.

If you look at the inline editor, you will see that the Dialogflow fulfillment library (which is written in NodeJS) is preloaded into it by default.

Why does this matter? It means the quickest way to get started with writing a webhook will be to use NodeJS, in which case you need to get familiar with the async paradigm.

3 You will graduate out of the inline editor when you build complex logic

While the inline editor is good to get started, and very useful as an education/training tool, you will need to graduate from using it when you start building complex business logic in your webhook.

For example, there isn’t any way to step through your code (for debugging) inside the inline editor. Nor is there a way to connect it with your source control so you can easily keep track of revisions.

4 The inline editor code is deployed to Google’s Cloud Functions for Firebase

When you click on the blue Deploy button below the inline editor, it will get deployed to Cloud functions for Firebase. These are ‘serverless’ functions which you can scale on demand (and there is also a free tier).

This can be very useful if you need your webhook code to scale infinitely.

5 Cloud functions are hard to test locally

However, using cloud functions comes with a limitation. It is not very easy to set up cloud functions on your local machine (remember that they have to simulate the environment they are running on) for debugging.

While there is documentation to emulate cloud functions on your local machine, I have noticed that it isn’t a very easy thing to setup.

6 The documentation for developing Assistant apps is NodeJS focused

Most of the documentation for developing Google Assistant apps is NodeJS focused. For example, the Actions on Google client library is only available for NodeJS right now.  If you want to use other programming languages to build Assistant apps, you will have to study the corresponding JSON and figure out how to send the JSON in your response from your webhook.

7 You need to use JSON if you want to build Assistant apps using non-NodeJS languages

You can build these Assistant apps if you figure out how to supply the correct JSON from your webhook code if you use a language other than NodeJS. (This process seems to be quite challenging, although I haven’t spent a lot of time on it yet).

Summary

So here is my summary:

Are you developing a non Google-assistant app?

Then stick to the programming language you are most familiar with.

Are you developing a Google Assistant app?

If you already are familiar with NodeJS or have NodeJS expertise on your team, choosing NodeJS is clearly a straight-forward choice.

On the other hand, even if you are not familiar, it is probably still a good idea to choose NodeJS as that’s the language in which you will find most of the documentation (and I imagine the trend of using NodeJS for most of the documentation will continue).

FREE COURSES

Related Posts